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ABSTRACT 


Extending the littoral battlespace (ELB) is vital to the United States Navy and 
Marine Corps. Fast, accurate, and reliable fire support will continue to be essential to the 
execution of Operational Maneuver From The Sea (OMFTS) and Ship-To-Objective 
Maneuver (STOM). The emergence of new technology has made these concepts 
possible. Technology will allow Marines to reach their objectives faster and farther then 
ever before. Information gathering, dissemination, and targeting will be key factors to 
the success of these new concepts. 

The development of low earth orbiting satellites that provide a seamless command, 
control, communications and intelligence (C4I) network will be necessary for ELB. This 
network will provide worldwide coverage, emphasize light forces with the ability to 
connect to larger forces and have a near zero footprint. The emerging communication 
architectures must have the capacity for voice, data, and video handling from high to 
narrow bandwidth. Developing a “light” communications architecture that supports these 
emerging concepts will allow ELB to be responsive for joint operations in the twenty- 
first century. 
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EXECUTIVE SUMMARY 


The doctrinal concepts of “Operational Maneuver From The Sea” (OMFTS) and 
‘Torward...From the Sea” adopted by the United States Marine Corps and Navy have 
shifted the focus of U.S. maritime strategy from open-ocean operations to littoral 
operations penetrating deep inland. This new littoral environment combined with new 
technology, including the Advanced Amphibious Assault Vehicle (AAAV) and the MV- 
22 Opsrey, allows for deeper and faster maneuver to objectives. This ability will impose 
new demands on littoral fire support and communications. 

The appearance of new technology on the commercial market such as 
cellular/satellite handsets and palm held computers have made personal computing and 
the ability to instaneously transmit messages around the world possible. Currently, the 
Marine Corps and Navy lack the ability for Marines to transmit naval surface fire support 
requests to ships from 200 miles inland to 100 miles “over-the-horizon” (OTH) as 
outlined by the OMFTS and “Ship-To-Objective Maneuver” (STOM). 

This thesis explores the possible benefits of using a low earth orbiting (LEO) 
satellite constellation for a communication backbone to request naval surface fires for 
great distances ashore. It will attempt to use a LEO system to “Extend the Littoral 
Battlespace” (ELB). 

It investigates the capabilities and limitations of three LEO systems, including 
bandwidth size, and time latency to span OTH distances that challenge an OMFTS 
forces’ ability to communicate to their sea based fire support center. It also uses 
modeling and simulation techniques to find coiiununication delay times and how these 
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results affect achieving objectives compared to current communication architectures. In 
addition, it makes a recommendation for future fire support communications. 


XX 



I. INTRODUCTION 


A. PURPOSE OF THESIS 

This thesis proposes a viable fire support communications architecture for the 
Extending the Littoral Battlespace (ELB) Advanced Concept Technology Demonstration 
(ACTD) 2001. This architecture supports the United States Marine Corps doctrine of 
Operational Maneuver From The Sea (OMFTS). The research will analyze 
communication and technology requirements needed to build an operational fire support 
architecture to support OMFTS operations from 100 nautical miles at sea to 200 miles 
ashore. 

1. Overview 

The United States Marine Corps concept for power projection ashore in the ever 
increasing littoral areas is described in its warfighting concept of “Operational Maneuver 
From The Sea” (OMFTS). [Ref. 1] 

2. Littoral Doctrine 

The Marine Corps doctrine of OMFTS is an overarching concept serving as an 
umbrella for the tenets of “Ship-To-Objective Maneuver” (STOM), ‘The MAGTF in 
Sustained Operations Ashore”, “Beyond C2”, and “Advanced Expeditionary Fire 
Support.” [Ref. 2,3,4 and 5] These combined concepts will Extend the Littoral 
Battlespace (ELB). FJ.B seeks an expeditionary force that is light, agile, potent, 
distributed and integrated. If this is achieved, the force will have enormous situational 
awareness and be supported by precise remote and loitering fires connected by a robust 
information infrastructure. By possessing a light, agile and potent expeditionary force. 
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the United States Marine Corps and Navy will be prepared to conduct operations in the 
littorals in all parts of the world. 

a. Operational Maneuver from the Sea (OMFTS) 

OMFTS is a response to both danger and opportunity. Danger is derived 
from the inherent chaos found in the littorals consisting of a clash of forces with national 
aspirations, religious intolerance, and ethnic hatred. Opportunity comes from the 
significant enhancements in information technology, battlefield mobility, and the lethality 
of conventional weapons. [Ref. 1] It is comprised of many elements. OMFTS focuses on 
an operational objective vice establishing waves for beach build-ups and it uses the sea as 
a maneuver space. Pitting friendly strengths against enemy weaknesses will generate 
overwhelming tempo and momentum. This new doctrine also emphasizes intelligence, 
deceptions and flexibility, and integrates all organic, joint, and combined assets. 

Command and Control systems will be very different than the processes 
developed for traditional approaches to amphibious assault. Communications systems 
will provide warfighters with control over information they need. They will also provide 
all units with the ability to communicate over-the-horizon. Successful execution of 
OMFTS will change fire support. Mobility ashore will improve dramatically by 
increasingly taking advantage of sea-based fires. To improve responsiveness and 
support, fire support coordination must be streamlined. Finally, to provide effective fires, 
forces afloat require the ability to deliver long range fires with greater accuracy and 
lethality. 

In the future, new technologies will give small units greater combat 
power. This will be accomplished through improvements in the precision of long range 
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weapons, greater reliance on sea-based fire support, and over the horizon 
communications. These elements make OMFTS possible and will revolutionize 
amphibious warfare. 

b. Ship-to-Objective Maneuver (STOM) 

STOM (see Figure 1) is a tactical concept for the actual amphibious 
operations discussed in OMFTS. It uses maneuver warfare concepts to extend the littoral 
battlespace. Landing forces will be capable of penetrating objectives deep inland from 
over the horizon. The tenets of maneuver warfare combined with the principles of 
OMFTS and STOM are a major evolution in amphibious warfare. 


OPERATIONAL MANEUVER FROM THE SEA 

- Focus ontiiB OperadioMal Objective 

- Treat fhe Sea as Maneuver Space 

- Create OveBvbelming Tempo aid Mbmenlnm 

- Apply S IrengiK Against Weajaies s 

Emphasis Intelligence, Deoepticci, and Flexibility 
Integrate Oiganic, Joini, and Combined Assets 


SfflP-TaOBJECIIVE MANEUVER 

- C ontiol Ten: 5 )oAD verwhelm adversary 

- Combined arms maneuver fiomOTH 

- Dilute the enen^b y enlaiging 
-Controlvitalareaby fighting outside it 

- Maneuver to cause an exploitable leactiou 


Figure 1. Ship-to-Objective Maneuver. [Ref. 2] 
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The improvements in mobility will free the commanders from the 
constraints of securing a large beachhead. This allows the landing force to focus on the 
enemy and begin maneuver from over the horizon. The combination of the maneuver 
warfare principles and emerging technologies will improve the naval force’s combat 
effectiveness. 

The cornerstone of STOM is the projection of combined arms teams 
ashore. These combined arms teams will rely heavily on sea-based command and 
control, logistics, and fire support. Landing forces vulnerabilities and footprint ashore 
will be greatly reduced by seabasing most supporting fires. This will improve freedom of 
maneuver thus enabling the naval force to project ashore combat formations that are 
leaner, lighter, and more effective. 

Successful implementation of the STOM concept will require 
improvements in command and control, and fires. Command and control allows a 
commander to recognize what needs to be accomplished and conraiunicates those actions 
to ensure mission completion. Maneuver warfare stresses decentralized execution with 
subordinate commanders exercising maximum latitude possible in performing assigned 
missions. This C2 system must provide commanders, at all levels, a common operational 
picture and connectivity to monitor execution and influence events when necessary. 

[Ref. 2] 

Fire support of STOM must provide immediate and responsive high 
volume suppression and neutralization fires for all levels of the landing force. Unit 
commanders at all levels will call for fire support and will be capable of controlling the 
fires of organic and supporting arms. This fire support system must be capable of 
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providing highly accurate and lethal long-range fires, and an “around the clock” all 
weather capability. Fire support agencies must respond for fire with sufficient speed and 
accuracy to support this highly mobile and maneuvering landing force. STOM will be a 
success by combining the foundations of maneuver warfare and the enabling technologies 
of today and tomorrow. This concept will give landing forces new capabilities never 
thought possible and will revolutionize amphibious operations. 

3. Scope of Thesis 

This thesis is a study that presents naval surface fire support requirements to 
extend the littoral battlespace and architecture requirements for over-the-horizon 
communications for naval expeditionary fire support. It also discusses three commercial 
satellite systems capable of providing a communications backbone for fires, and selects 
one architecture modeled in a PC based network design tool and simulated in a combat 
simulation software. This thesis examines the following research questions: 

1. Primary research question: What communication architecture currently 
being developed and possible future ones will best provide the means to 
transport targeting data for supporting fires in the most efficient manner to 
extend the littoral battlefield? 

2. What communication architecture can be developed to support the 
concepts of OMFTS and STOM from the individual Marine to a MEF 
size fire support element? 

3. What are the bandwidth requirements and what comprises this bandwidth 
for fire support data in these new operational concepts? 
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What have been the fire support communication requirements for a MEU 
size force based on new tactics as performed in Urban Warrior, Hunter 
Warrior, and Extending the Littoral Battlefield ACTD 1999? 

5. What are the comparisons of the capabilities and limitations that the 
LEO/MEO companies can provide? 

This thesis is limited to reviewing and analyzing three commercial satellite 
systems that could be used as a communications backbone for advanced expeditionary 
fire support. One will be recommended for supporting naval surface fires to support the 
ELB Advanced Concept Technology Demonstration (ACTD) 2001. It assumes the 
reader has a working knowledge of advanced warfighting concepts and communications 
terminology. 

B. RESEARCH METHODOLOGY AND ORGANIZATION 

1. Research Methodology 

This thesis was initiated to possibly assist the Office of Naval Research (ONR) 
and the United States Marine Corps C4I and Architectures Requirements Division for 
ELB ACTD 2001. Sources of information for this research were literature searches 
conducted throughout Department of Defense (DOD) and commercial industries. 
Information from classes attended throughout the Naval Postgraduate School and 
interviews and discussions conducted with subject matter experts while on an experience 
tour at ONR were also used. 


6 



2. Organization 

This thesis is organized as follows: 

a. Chapter II 

Chapter n discusses extending the littoral battlefield concepts and 
requirements. It reviews the capabilities sought for ELB ACTD 1999 and ACTD 2001. 
The technical challenges of these ACTD’s are presented and ACTD ’99 is discussed in 
detail. The communication requirements and problems for naval surface fires to support 
ELB, OMFTS, and STOM are introduced. 

b. Chapter III 

Chapter HI defines naval surface fire support. It examines the process and 
procedures of naval expeditionary fire support for future waifighting concepts. Systems 
currently being used and future ones are introduced. Warfighting experiments such as 
Hunter Warrior and Fleet Battle Experiments are reviewed and lessons learned are 
discussed. 

c. Chapter IV 

Chapter IV presents three satellite systen^ (Globalstar, Iridium, and 
Teledesic) and their ability to provide a communications backbone for fire support. A 
brief description of each constellation covering communication structure, orbits, and 
satellite characteristics will provide the general knowledge necessary to develop a mental 
picture of each system concept. The focus will be a comparison of each system using the 
ELB ACTD requirements to determine the best constellation support for ELB, OMFTS, 
and STOM. 
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d. Chapter V 

Chapter V describes the use of a software based PC modeling tool. 
Extend, to model the three commercial satellite systems combined with a baseline naval 
expeditionary fire support communications architecture. This architecture will support 
ELB, OMFTS, and STOM employment schemes. The results of this model, time latency, 
bandwidth, collision count, and successful messages delivered, will be used as input into 
the combat simulation runs for effects on mission accomplishment. 

e. Chapter VI 

Chapter VI describes the use of the high-resolution model Joint Combat 
and Tactics Simulation (JCATS). First, a run is conducted using current fire support 
techniques and communication architectures. Conununication delay times are derived 
from the PC based modeling done for current procedures. This simulation run is then 
compared to another run based on future communication architecture for naval fires. 
These two runs are compared to find the effects that the different architectures have on 
mission accomplishments. 

f. Chapter VII 

This final chapter presents the final conclusions drawn from the research 
and provides recommendations for further study in this area. 
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11. EXTENDING THE LITTORAL BATTLESPACE 


A. BACKGROUND 

Extending the Littoral Battlespace (ELB) incorporates the concepts of OMFTS, 
Forward...From the Sea, Joint Vision 2010, STOM, and Advanced Expeditionary Fire 
Support. The Office of Naval Research (ONR) established the Advanced Concepts 
Technology Demonstrations (ACTD) for ELB from a Broad Agency Announcement 
dated May 7, 1997. The concept of an ACTD is a new approach to provide users with 
detailed interactions early in the developmental process, and as an effective means of 
getting capabilities rapidly into the field at reduced costs. The primary objective is to 
accelerate and facilitate application of mature advanced technologies to solve important 
military problems and thereby providing operational capabilities that will make a 
difference to the warfighter. [Ref. 6] 

B. OBJECTIVES 

The objective of the ELB ACTD is to demonstrate the military utility of a 
revolutionary concept for joint expeditionary warfare enabled by advanced technology. 
[Ref. 7] Combat units with multiple weapon systems will be integrated with command 
elements to defeat any adversary in the 21®* century in an extended littoral battlespace. 
The resulting ELB ACTD will be a complete, end-to-end capability to perform four key 
functions: Communications, Command and Control (C2), Sensing, and Fires and 
Targeting. Program objectives will be achieved through a series of limited technical 
experiments leading up to the two major operational demonstrations. A Marine 
Expeditionary Unit (MEU) size element comprising of 5-10 ships, 30 armored vehicles. 
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30 fixed/rotaiy wing aircraft, and 2,000 Marines will be used for the demonstrations. The 
capabilities must be scalable up to a Marine Expeditionary Force (MEF). 

ELB ACTD ’99 took place in April 1999 of the coast of San Diego, California. 
The objective of this ACTD was to demonstrate a system that integrates the core 
capabilities in four areas (Communications, C2, Sensing, and Fires and Targeting) in a 
military useful, user-friendly system. Areas examined include a flattened, rapid, webbed, 
distributed C2 process and an order of magnitude improvement in combined fires 
response time. 

F.T .B ACTD 2001 will build upon the results and developments of the ACTD ’99. 
A system with more complete capabilities and improved robustness will be achieved for 
the ’01 ACTD. If successful, the system may be deployed to an operational unit and 
additional systems procured. 

These systems must be capable of supporting a MEF size element consisting of 50 
ships, 425 armored vehicles, 350 fixed/rotary wing aircraft, and 50,000 Marines 
operating from over 100 miles at sea to 200 miles inland. Responsive sensing, 
communications, decision-making, and firepower over this extended area are the keys to 
the overall effectiveness of the ELB concept. [Ref. 7] Small deployment operations 
should be possible with near-zero infrastructure. 

C. CONCEPT OF OPERATIONS 

The FT.B demonstrations exploit the operational concept of “Forward...From the 
Sea” and OMFTS. They seek to demonstrate a seamless command structure between 
afloat and ashore units thus allowing peer-to-peer communications and command by 
exception. Small units ashore will engage targets from greater distances, calling in 
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supporting foes from weapon platforms at sea or loitering weapons. Forces will operate 
in wider dispersed formations in a non-linear fashion, and will be capable of massing 
fires rapidly from dispersed locations. These units will be able to request fires from well 
beyond the line-of-sight of communications. 

A communications architecture and fire support capability designed to support 
small combat units will require a flattened informational structure. Teams will seek to 
avoid direct firefights and will rely upon remote weapons to engage the enemy. 
Survivability is increased by the employment of numerous small, stealthy teams since 
they produce a smaller target. 

D. ELB NARROWBAND COMMUNICATIONS 

Co mmuni cations systems for ELB will supplement and complement existing 
USMC/USN communication and information systems. The ELB demonstrations will 
attempt to achieve two major areas of improvements to make OMFTS and 
‘Torward...From the Sea” possible. One will be a responsive, timely, narrow-band 
“cellular-like” voice and data to and from distributed ground forces and weapons over the 
entire area of operations. This area of operations is extended to cover approximately 300 
miles, 200 miles inland and 100 miles over the horizon. The second area the 
demonstrations will investigate is a wide-band service. This service will be used by 
distributed command and control elements, the warfighting CINCs, as well as 
intelligence surveillance reconnaissance elements. This research will address the narrow- 
band capabilities and requirements to provide a rapid and responsive naval fire support 
architecture. 
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1. Challenges 

There are many technical challenges to delivering the desired system for ELB. 
The first challenge is the distance to be covered by this communication architecture for 
naval surface fire support. In the past, naval gunfire support has been achieved through 
the use of line-of-sight (LOS) or high frequency communications. Achieving networked 
fire support communications over a swath of 300 miles will be difficult using existing 
communications equipment. Many links, limited to approximately 20 miles (LOS), 
would be needed. These links present multiple points of failures and each site must be 
defended which takes more manpower. The use of a commercial, cellular based system 
would overcome this distance challenge but a cellular system may not be available in all 
areas of operations. A spacebome system such as a low earth orbiting (LEO) 
constellation or an airborne system will overcome the distance problem. These space 
systems commonly provide low bandwidth (2.4-9.6 KBPS), however future systems 
should provide more bandwidth. Bandwidth problems arise with the combination of 
supporting multicast and “push and pull” data from the dismounted warriors. There 
could also be a problem with “busy” signals. Though these potential difficulties exist 
today, they can be overcome by the use of a narrow-band “cellular-like” system. [Ref. 6] 
Existing military satellite communications and hybrid military/commercial 
systems such as INMARSAT are useful, they cannot fulfill the OMFTS firesupport 
requirements. The most important reason that these systems would not meet the desired 
characteristics of the narrow-band network is that military satellite communications were 
not designed to support a large number of individual warriors. 
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Another challenge that has to be conquered is the achievement of an integrated 
network. Important issues for this integrated network such as the ability of the 
communications equipment to support both voice and data and the possibility of 
multicasting have to be resolved. Also, the system has to be able to integrate Internet 
Protocol (IP) addressing with cellular/PCS addressing and be incorporated into legacy 
systems. This challenge of an integrated distributed network must be met for the reality 
of a narrow-band system to take shape. 

The power requirements, battery usage, and weight of the equipment are 
additional challenges. The fire support system is designed to support small, dismounted 
“hunter-killer” teams. These teams will need a lightweight unit for connectivity into the 
file support network. To achieve this, a low battery power requirement will be necessary 
for a hand-held digital personal computer and transmission media. The desired system 
will be small (less than 1 kg) and a power requirement of less than 1-5 watts during 
transmission. This equipment must be configured to wear on the body. 

This integrated fire support network must also meet the challenge of being 
operated in various terrain. This system has to be capable of communicating in terrain as 
dense as jungle canopies, as difficult as mountainous areas, and as open as desert terrain. 
Also, this new communication equipment must be able to be operated in an urban 
environment. Though current systems have difficulties communicating in all of these 
environments, future technological advances may be leveraged to meet these challenges. 

The emergence of personal conununication systems (PCS) has made 
communicating worldwide on a hand-held terminal possible. The initial introduction of 
these systems was cellular wireless technology thus limiting communications to areas 
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where “cells” were located. The introduction of LEO constellations provides a new form 
of PCS. These systems will be able to communicate in all environments because of the 
satellite constellation footprints and coverage. Instant, worldwide communications will 
be possible. 

2. Desired Capabilities 

ONR has established the desired capabilities of the narrow-band communications 
system for both the ACTD’s 1999 and 2001. The ACTD 2001 will build on the results 
from ACTD ’99 and seek to expand the scale of operations from a MEU size element up 
to a MEF size. Regardless of demonstration, the narrow-band system will interconnect 
small-deployed units. This “cellular” system will be deployed to fire team leaders (i.e., 
2-3 per squad) and use small hand-held terminal devices that can receive digital data from 
GPS and from target location devices. [Ref. 8] This terminal device must be able to 
support the following applications: 

* Calls for fire 

* Medevac 

* Resupply requests 

* Forward observer reports 

* Situation awareness 

* Commands and other directions 

* Weather reports 

* Very low resolution map overlays 

* Position and ID reporting 
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a. ACTD ’99 


The ACTD ’99 (Phase 1) system seeks the capability to support 100-200 
handsets with the capability to connect to each other and to the Enhanced Combat 
Operations Center (ECOC). ONR’s request for proposals state that the connection times 
for these users should be less than 15 seconds and the digital queuing/time latency less 
than one second. Also, the data rate after error detecting/correcting coding must be 
greater than 2.4 kbps. For the Phase 1 demonstration, digital voice and data may be 
separate connections (i.e., a handset may be used for voice or for data but not at the same 
time). [Ref. 8] 

b. ACTD ’01 

The ACTD ’01 (Phase 2) system should include all of the objectives of the 
Phase 1 system and be capable of supporting a single MEU with the ability of scaling up 
to a MEF. The Phase 2 system must be able of supporting 200 to 300 narrow-band users 
with the ability to connect to each other and to the ECOC. The system will be more data- 
centric than in Phase 1 with the ability to “push and pull” data over a single connection. 
Also, it must be capable of interconnecting narrow-band and wide-band systems 
providing voice, email, and file transfers. Finally, this system must be able to multicast 
and not be a strict point-to-point system. [Ref. 6] 

c. Notional Operational Architecture 

The ELB operational architecture (see Figure 2) will incorporate current 
USMC/Navy communications and information systems. It will also provide the two 
additional capabilities of the narrow-band “cellular” system for dismounted distributed 
ground forces and wide-band services among distributed command and control elements. 
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This ELB communication architecture is an ensemble of systems in which no one system 
will provide all connectivity and services. [Ref. 8] 



Figure 2. ELB Notional Communication Architecture. [Ref. 8] 


The traffic loads for the narrow-band system depends upon the military 
mission, phase of operation, and command structure chosen for the operation (i.e., 
hierarchical command or “flattened” stmcture). There has been no definitive amount of 
information messages exchanged but efforts have been conducted on probable traffic 
loading requirements on the narrow-band system. 

The Hunter Warrior Exercise provided the first estimate of information 
exchange requirements. The data requirements from this experiment for each narrow- 
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band system were one 256 bit position report every 5 minutes and one 512 bit message 
every 30 minutes to the ECOC. During fire fights, 10% of the radios may be sending 
calls for fire once per minute for 15 minutes average duration. [Ref. 8] These messages 
should be received and acknowledged by the ECOC within 10 seconds from time of 
sending. Information from the ECOC to narrow-band units will be one 2000-bit sitmap 
update every 15 minutes, One 512 bit message every 15 minutes, and one 10,000 bit firee 
text operation order every 6 hours. A multicast capability that can be organized by 
geographic location, command structure, or force element is required. 

The second estimate is based on a simulation analysis (see Tables 1 and 2) 
that explored the use of an airborne relay to support amphibious operations. This 
simulation used two MEU’s for the assault and 11 Navy ships but no Army activity. The 
list below identifies the message type, source and destination, approximate frequency of 
transmission, and message in bits. To facilitate reading Tables land 2, a 
acronym/abbreviation list is provided in Table 3. 
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Message Type 

Connectivity 

Periodicity 

Message size 
(bits) 

Observer Status 

SpotTMtoSACC 

every 15 min 

150 


SACCtoJTFNode 

every 15 min 

300 

Observer Position Report 

SACCtoJTFNode 

every 15 min 

1400 

Position Report 

SpotTMtoSACC 

every 15 min 

700 

Spot Report 

SpotTMtoSACC 

every 15 min 

1000 

Shot-at-Report 

SpotTMtoSACC 

every 15 min 

100 

MSG to Observer 

Shooter - Spot TM 

every 15 min 

1250 

Subsequent Adjustment 

Spot TM - Shooter 

every 7 min 

750 

Observer Notification 

Shooter - Spot TM 

every 7 min 

650 

End of Mission 

Shooter - Spot TM 

every 15 min 

1000 


JTFNode-SACC 

every 8 min 

2000 

Target List 

SACC-JTFNode 

every 15 min 

8000 

Mine Danger 

MCMTA - Assets 

every 60 min 

5000 

Platform Status 

Asset - MCMTA 

every 60 min 

2000 


Asset - Asset 

every 60 min 

1000 

Mine-like Contact 

Asset - MCMTA 

every 60 min 

20000 

Mine-like Contact 

MCMTA - Asset 

once each ipt 

20000 


Asset - Asset 

once each asset 

2000 

Mine Report 

Asset- MCMTA 

every 6 min 

2000 

Mine Actuation 

Asset - Asset 

every 20 min 

2000 

Convoy Schedule 

MCMTA - Asset 

every 60 min 

1000 


Table 1. Approximate minimum specification of communication traffic to support 
the pre-assault phase of a 2 MEU amphibious attack. [Ref. 8] 
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Message Type 

Connectivity 

Periodicity 

Message 
Size (bits) 

Mine Danger Report 

CCO - PCS, SCS, LFSP 

every 15 minutes 

5000 


PCS - Beach Party 

every 15 minutes 

5000 


PCS - Boat Group CDR 

every 15 minutes 

5000 


SCS - all ships 

every 15 minutes 

5000 


CLF - all nodes 

every 15 minutes 

5000 


AA Co CDR - all nodes 

every 15 minutes 

5000 


MA Co CDR - all nodes 

every 15 minutes 

5000 

Threat Warning 

CATF - all nodes 

every 15 minutes 

700 


PCS - Beach Party 

every 15 minutes 

700 


PCS - Boat Group CDR 

every 15 minutes 

700 


SCS - all nodes 

every 15 minutes 

700 


CLF - all nodes 

every 15 minutes 

700 


AA Co CDR - all nodes 

every 15 minutes 

700 


MA Co CDR - all nodes 

every 15 minutes 

700 

OPORD Boats 

CCO-PCS, SCS, LFSP 

every 15 minutes 

2000 


PCS - Beach Party 

every 15 minutes 

2000 


PCS - Boat Group CDR 

every 15 minutes 

2000 

OPORD LCAC’s 

CCO-SCS, LFSP 

every 15 minutes 

2000 


SCS - all nodes 

every 15 minutes 

2000 

OPORD MA Co 

CLF-AA Co CDR 

every 15 minutes 

2000 

OPORD AA Co 

CLF-MA Co CDR 

every 15 minutes 

2000 

OPORD General 

CLF - all nodes 

every 15 minutes 

2000 

OPORD 

AA Co CDR - all nodes 

every 15 minutes 

2000 


AA PLT LDR - SQD LDRs 

every 15 minutes 

2000 


MA Co CDR - all nodes 

every 15 minutes 

2000 


AAPLTLDR-AAVs 

every 15 minutes 

2000 

REDCONMOPP 

CATF - all nodes 

every 15 minutes 

100 


PCS - Beach Party 

every 15 minutes 

100 


PCS - Boat Group CDR 

every 15 minutes 

100 


SCS - all nodes 

every 15 minutes 

100 


CLF - all nodes 

every 15 minutes 

100 


AA Co CDR - all nodes 

every 15 minutes 

100 


MA Co CDR - all nodes 

every 15 minutes 

100 

Boat Position Rept 

PCS-CCO 

every 15 minutes 

150 

Boat Group Position 

Boat Group CDR - PCS, 

every 15 minutes 

150 

LCAC Position Rept 

SCS 

every 30 seconds 

150 


SCSS-CCO 

every 30 seconds 

150 


LCAC Group CDR - all 

every 15 seconds 

150 

Position Sununary 

ships 

every 15 seconds 

300 


LCAC Group CDR-all 

every 15 seconds 

600 

SITREP 

ships 

every 60 seconds 

1500 


AA Co CDR-CLF 

every 60 seconds 

1500 


19 












MACoCDR-CLF 

every 15 minutes 

1500 


All ground nodes - CATF 

every 15 minutes 

1500 


Node - node 

every 15 minutes 

1500 


Nodes - all nodes 

every 15 minutes 

1500 


Boat Group CDR - PCS, 

every 15 minutes 

1500 


SCS 




SCS-CLZCTLTM 

every 15 minutes 

1500 


LCACRGPCDR- 

every 15 minutes 

1500 


SCS,CLZCTLTM 

every 15 minutes 

1500 


CLZCTLTM-SCS 

every 15 minutes 

1500 

PCS Position Report 

All nodes - CLF 

every 15 minutes 

1500 

SCS Position Report 

All nodes - AA Co CDR 

every 15 minutes 

1500 

Position Report 

AA SQD LDRS - AA PLT 

every 30 seconds 

150 


CDR 




All nodes - MA Co CDR 

every 60 seconds 

600 


AAVs-AAPLTLDR 

every 60 seconds 

600 

Obstacle Report 

PCS - all ships 

every 60 seconds 

600 


SCS - all ships 

every 7 minutes 

600 

Bridge Report 

AA Pit LDRs - AA Co CDR 

every 15 minutes 

1000 


AA SQD LDRs - AA PLT 

every 15 minutes 

1000 


LDR 

every 15 minutes 

1000 

Land Route Report 

AAVs-AAPLTLDR 

every 15 minutes 

1000 

Logistics Report 

SpotTM-SACC 

every 15 minutes 

1000 

MEDEVAC Request 

CLZ CTL TM - all ships 

every 5 minutes 

500 

Observer Status 

MA Co CDR-CLF 

every 7 minutes 

500 

Report 

PLT LDR - MA Co CDR 

every 15 minutes 

1500 

Observer Position 

AA Co CDR - CLF 

every 15 minutes 

1000 

Report 

OLRLDR-AACoCDR 

every 7 minutes 

150 

Observer Notification 

MA Co CDR-CLF 

every 7 minutes 

300 

Report 

PLT LDR - MA Co CDR 

every 15 minutes 

1400 

Spot Report 

All nodes - TACLOG 

every 15 minutes 

650 

Shot-at-Report 

MEDTM-TACLOG 

every 7 minutes 

1000 

Call for Fire 

SpotTM-SACC 

every 15 minutes 

100 

Fire Adjustment 

S ACC - JTF nodes 

every 15 minutes 

1000 

MSG to Observer 

S ACC - JTF nodes 

every 2 minutes 

750 

End of Mission 

Shooter - Spot TM 

every 7 minutes 

1250 

Target list 

SpotTM-SACC 

every 15 minutes 

1000 

Tactical Air Request 

Spot TM - S ACC 

every 15 minutes 

2000 

Tactical Air Request 



4000 

Acceptance 



1500 




650 


Table 2. Approximate minimum specification of communication traffic to support 
the assault phase of a 2 MEU amphibious attack. [Ref. 8] 
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Acronyms 

AA: Airborne Assault 

MA: Mechanized Assault 

AFOE: Assault Follow-On Echelon 

LCO: LCAC Control Officer 

LAV: light Armored Vehicle 

CCO: Central Command Officer 

SACC: Supporting Arms Coord. Center 

SCS: Secondary Control Ship 

SCO: Secondary Control Officer 

MCMTA: Mine Counter Measure Tactical 


LCAC: Landing Craft, Air Cushion 
MCAC: Minesweeping Craft, Air Cushion 
LCU: Landing Craft 
AAV: Amphibious Assault Vehicle 
CATF: CDR Amphibious Task Force 
CLF: CDR Landing Force 
PCS: Primary Control Ship 
PCO: Primary Control Officer 
NSFS: Naval Surface Fire Support 
Authority 


Table 3. Table of acronyms and abbreviations for Tables 1 and 2. [Ref. 8] 


The fire support architecture developed in this thesis will add more fire 
support messaging in an attempt to add more stress to the system. The notional 
operational architecture must be capable of supporting these information exchanges in the 
appropriate time manner. 

E. FIRES AND TARGETING (F&T) 

This section on F«&T describes the activities and identifies the functions needed 
for the warfighter to be successful rather than focus on a particular system. Targeting is 
the process of identifying and selecting enemy targets and matching the appropriate 
weapon or munitions to capture, destroy, degrade, or neutralize it. The warrior goes 
through inherent functions when conducting targeting. These functions are deciding, 
detecting, and delivering. 

1. Deciding 

The deciding function is on-going. It is the need to specify a prioritized list of 
targets to be acquired and attacked. This function also lays out preliminary plans for 
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when and how to attack targets, and develops a preliminary plan for acquiring target 
information to enable execution decisions to be made. One of the most important features 
of this function is that it develops guidance for coordination among joint forces and 
maintains an up-to-date inventory of available weapons. This function, especially the 
weapon inventory, can be automated and two particular systems are discussed in the 
following chapter. 

2. Detecting 

The detect function provides continuing information collection to the decide and 
deliver functions to insure that they are coordinated. This function can either execute the 
collection plan and directly control the target sensors (i.e. human or machine) or monitor 
the collection process and extract necessary data. Regardless, it is responsible for 
acquiring targets and extracting the necessary information for decision-making and 
weapon employment. This essential information includes the date time group (DTG) the 
target is detected, target identification, location, description, and any other data that may 
be needed by the weapon system that is going to engage the target. [Ref. 9] It is vital that 
standard message format for disseminating targeting information be used to expedite the 
decide and deliver processes. 

3. Delivering 

The deliver function carries out the attack guidance and supports the 
commander’s battle plan. This function uses preplanned guidance and information from 
the decide function including any scheduled targets or time critical targets. Determining 
time on target or time of launch, desired effects on targets, weapon/target pairing, number 
of munitions per target, allocation of targets to weapon-launch platforms, and fire 
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coordination are results of the deliver function. This function provides both fire 
schedules and action reports to the decide and detect functions. 

F. SUMMARY 

ELB seeks to make OMFTS a realistic concept. Using the challenges of OTH 
communications, bandwidth requirements, and the desired capabilities sought by ONR, 
this thesis will propose an end user terminal, fire support systems, and a narrow-band 
communications backbone to improve the F&T functions. This improvement will speed 
up the “steel-on-target” time, improve distances, and help make OMFTS a reality. 
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m. NAVAL SURFACE FIRE SUPPORT 


A. PROCEDURES 

Amphibious operations are the most complex of all military operations. Fire 
support coordination procedures between the Navy and Marine Corps require a common 
understanding for success of the operation. [Ref. 10] The goal is to integrate all naval 
fires to produce the most effective form of power projection ashore. In amphibious 
operations, the Commander Amphibious Task Force (CATF) is the overall commander of 
the operation. The CATF commands all elements of the Amphibious Task Fore (ATF), 
including the fire support elements. Because these fire support elements are organic to 
component commanders, command of the fire support elements seldom changes. The 
CATF’s command of landing forces (LF) fire support elements is exercised through the 
Commander Landing Forces (CLF) as a component conunander. The CATF’s fire 
support responsibilities consist of planning, targeting, controlling, coordinating, and 
monitoring fire support activities. The MAGTF commander is the CLF during 
Navy/Marine Corps amphibious operations. The CLF has the responsibility for the 
coordination of LF requests for fire support during all phases of the operation. Requests 
for air and naval fire support are presented to the CATF for prosecution, the CLF plans 
and controls artillery for the operation. [Ref. 11] 

The CATF establishes a Supporting Arms Coordination Center (SACC) at the 
ATF level of the amphibious organization. The SACC is the single location on board an 
amphibious connnand ship in which all conununication facilities reside to provide 
coordination of fire support for artillery, air and naval fire support. [Ref. 11] The SACC 
is staffed with personnel from the ATF and representatives from the LF. 
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Initially, the CATF controls air support, naval fire support and artillery, through 
the CLP. As the first IP elements reach the shore, the portion of control that relates to 
the firing of specific missions in support of the IP shifts to those elements. With the 
commencement of on-call fires, the control of supporting arms in the attack of specific 
targets becomes a IP responsibility when the target affects the LF. [Ref. 11] 

The SACC’s role is primarily supervising the execution of a detailed fire support plan. 
Subordinate units within their own boundaries and with adjacent units accomplish 
coordination of supporting fires, with SACC assistance when required. Subordinate Fire 
Support Coordination Centers (FSCCs) do not assume action until after execution of the 
overall ATF planned fires and after FSCCs are ashore. The SACC makes appropriate 
coordination to achieve a combined arms effect. The CATF phases the responsibility for 
appropriate fire support coordination and control to the CIP when IPs are phased ashore 
and operating effectively. The CIP then coordinates the fires of all supporting arms with 
troop maneuvers. The SACC assumes a monitoring status, prepared to take control and 
coordination responsibility if required. [Ref. 11] 

B. CONCEPTS 

Naval fire support is a combination of all assets afloat used to support forces 
ashore during the initial phases of amphibious operations. Many documents such as Joint 
Vision 2010, Forward...From the Sea, OMFTS, and the Navy Operational Concept have 
attempted to define this subject in order to develop what is called the Naval Fires 
Concept. Along with these documents other factors have been used to define this 
concept. These factors include: 

• The legacy of current capabilities and procedures. 
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• New technologies enhancing capabilities. 

• National policy concerning implementing new technologies. 

• Political-military environment. 

• Uncertainty of the littoral environment. 

• Employment concepts of ground forces in the littorals. [Ref. 12] 

The Naval Fires Concept is focused upon integration of fires instead of 
coordination of fires. Coordination is the sharing of information among operational units 
as to the timing and location of fires and maneuvers so as to avoid fratricide and 
duplication of effort. Whereas, integration is the sharing of information among operating 
units so as to collaboratively plan and execute a scheme of fires and maneuvers whose 
effects are reinforcing, and complimentary, and which combine to achieve a mutual 
objective. 

The differences between these concepts is that focusing on the integration of fires 
allows for improvements in operations regardless of the level of improvements in 
technology. If technology fails to advance as planned, operations can still be improved 
using existing systems. However, if technology does keep pace, as envisioned, then 
integration provides for operational improvements to keep pace with technological 
improvements. The following concepts use integration of fires for success of the 
operations. 

1. Advanced Expeditionary Fire Support 

The warfighting concepts outlined in OMFTS and STOM apply the tenets of 
maneuver warfare. Greater emphasis must be placed on speed, mobility, firepower, and 
communications to rapidly exploit enemy weaknesses to achieve decisive results. A sea- 
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based fire support and command and control (C2) system must be used to the maximum 
extent possible. This will allow greater freedom of maneuver ashore while also 
improving force protection. In OMFTS and STOM, these naval expeditionary fires will 
surprise the enemy and create favorable conditions for landing forces. 

The advanced expeditionary &e support system must be flexible, robust, and 
capable of providing responsive, precise, and all-weather fire support (see Figure 3). 
This system must combine an array of precision, area, and loitering weapons with greater 
range, improved accuracy and lethality. Combining precision guided munitions and 
accurately delivered non-precision weapons will provide an optimal mixture of 
munitions. Fire support changes over the course of amphibious operations. Initially, 
commanders seek to shape the battlespace to facilitate STOM without comprising tactical 
surprise. The fires necessary to shape this battlespace will need to provide long-range, 
precision fires capable of destroying or neutralizing key enemy capabilities. During 
STOM, high volume suppressive fires will be vital. Naval surface fires and aviation 
support will provide most of this support. Once forces are ashore and fighting deep 
inland, naval, aviation, and ground fires will provide fires in support of objectives. 
Executed properly, OMFTS will seek to maximize the use of sea-based fires (see Figure 
4). 

Fire support systems consists of three elements: command and control, target 
acquisition, and weapon systems. C2 gives the commanders the ability to influence 
action. It allows a means for sharing information, selecting weapons systems to engage 
targets, and controlling and coordinating fire support. Target acquisition is the 
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identification, location, and analysis of targets. Weapon systems provide the means for 
attacking targets. 

A single integrated (ground, air, naval, and joint) C2 system must exist for 
expeditionary fire support to be successful. Maneuver elements, often operating deep 
inland, require highly responsive fires in support of their maneuvers that will quickly 
attack enemy targets. This C2 system must permit commanders to direct fires, based on 
tactical situations, firing systems available, response time, weapons available, and 
commander’s guidance. It must also allow the landing force to request and receive fires 
any time. Fire support coordination must be streamlined to improve responsiveness. C2, 
target acquisition, and weapons must be improved to support OMFTS. 


Key Capabilities 

The advanced expeditionary fibre support system must be able to provide: 

• A single, integrated command and control system 

• Flexibility through aviation, naval surface, and ground-based fibre support 

• Precision point fibres 

• Accurate, high-volume fire 

• Lethal and non-lethal munitions 

• Mobility equal to that of the ground maneuver element 

• Sufficient range to protect the force and shape the battlespace 

• Responsive support for maneuver and force protection 

• Maximum use of seabasing 

• Minimization of logistics support requirements. 


Figure 3. Advanced Expeditionary Fire Support Key Capabilties. [Ref. 5] 


The challenge of OMFTS and STOM is to provide continuous, responsive fire 
support to rapidly maneuvering forces. Fire support for these new warfighting concepts 
support requires an over-the-horizon, high capacity communications architecture. These 


29 







communications must be robust, flexible, and connected to a sea-base for effective naval 
surface fire support. The C2 system must provide commanders and firing agencies a 
shared tactical picture and the ability to use naval fires to instantly influence tactical 
scenarios. The ability to process fire requests and engage targets rapidly is crucial. 
“Reducing target engagement time, especially time of flight for naval surface fires, is 
critical to supporting the landing force because seabased systems will provide the 
majority of fires during the initial phases of the operation.” [Ref. 5] 


OMFTS from a Fire Support Perspective 

• A single, integrated, seabased command and control system will provide a 
common, real-time battlefield picture to commanders and fire support 
elements, links to target acquisition and intelligence systems, and coordination 
and control for aviation, naval surface and ground-based fires. 

• All fire support systems will be sustained primarily from the sea, 

• Fires will both enable and exploit maneuver. 

• Fire support will be capable of providing a range of effects appropriate to the 
situation, including non-lethal fires. 

• Complementary aviation, naval surface, and ground-based fire support 
systems will provide flexible, reliable, and synergistic fire support. 

• Naval surface fire support will provide long-range, accurate fires to shape the 
battlespace and support the maneuver force. 

• Aviation fires will support both the close and the deep battle. Naval aviation 
will be capable of operating ashore from expeditionary airfields when 
advantageous, 

• Ground-based fires will provide mobile, responsive, all-weather support. They 
will directly support ground operations and facilitate aviation and naval 
surface fires, for example, by suppressing enemy air or antiship defenses to 
enable the delivery of friendly aviation and naval surface fires. 


Figure 4. Advance Expeditionary Fire Support Perspective. [Ref. 5] 


These improvements in the key capabilities of an amphibious expeditionary fire 
support system will enable Marine Air Ground Task Force (MAGTF) commanders to 
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generate overwhelming combat power, tempo, and momentum. This evolution in naval 
fire support, whether used in STOM or other expeditionary operations, will permit the 
MAGTF to achieve decisive actions in OMFTS. 

2. Ring of Fire 

The Ring of Fire (ROF) concept is a method of making naval fire support 
successful. ROF is described as a local area network comprising a joint fire control 
network and a joint planning network. Each ship in the ring will have the ability to 
launch land-attack weapons fi*om other ships in the ring remotely. A ship that is closest 
to the fight can concentrate on protecting itself and any other supported forces, while 
land-attack weapons can be launched remotely by a more distant ship. Automating these 
decisions will expedite the process of passing fire missions from sensor to shooter, 
eliminating errors associated with voice tasking and reducing the time from ordering 
missions to ordnance on target. Seven functions are necessary for ROF to successfully 
coordinate naval fire support: 

• Ability to launch land-attack ordnance remotely from any weapons 
platform. 

• Auto-force inventory. 

• Ability to apportion ordnance to warfare commanders. 

• Auto-pairing of ordnance to targets. 

• Common information sharing by all providers and users. 

• Automated and integrated deconfliction tools. 

• Ability for each land-attack fire control to be the master or decision maker 

station. [Ref. 13] 
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C. FIRE SUPPORT SYSTEMS 

The joint littoral operations force of 2010 may be an entirely sea-based force, or it 
may be partially sea-based and partially shore-based. If the latter, the preponderance of 
forces and headquarters may be at sea or they may be ashore. Alternatively the 
headquarters may be one place and the preponderance of forces another. A robust C4ISR 
system will allow for geographic separation of commanders and virtual collocation. The 
naval component of the force may be conducting the initial operations, or it may be 
joining operations in progress - bringing massed firepower of carriers, cruisers, 
destroyers, and submarines to the support for forces ashore. 

The role of naval fires in the future will become more complex, and we must find 
a way to plan for, adapt to, and overcome these complexities. Several key capabilities are 
required to ma ximiz e the role of naval fires in the littoral regions, two of which are 
related to the focus of this thesis. 

A naval fire support C4I system that is automated, reliable, interoperable, and has 
OTH capabilities is essential. Such systems must allow ground units deep inland as well 
as those in valleys close to the coast continuous access to the fires integration center and 
a shared operational picture. They must allow integration of naval fires with joint fires 
when the Joint Force Commander is ashore. They must allow virtual staffing for the 
engagement commander by providing real time access to distributed expertise and data 
bases for planning as well execution. Embedded planning and execution tools that 
interface directly and efficiently with databases must be established. While highly 
centralized for planning, the C4I system must allow for both centralized and 
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decentralized execution to avoid single node vulnerability to attack or failure. The 
following naval fire support systems provide the aforementioned capabilities. 

1. Land Attack Warfare System (LAWS) 

LAWS is a system developed by the U.S. Navy for use in conducting naval fires 
in support of land operations. It is designed to fully automate the targeting, weaponry 
and information flow of fire support from naval forces afloat to land forces ashore. It is a 
networked, near real-time system that displays all pertinent information such as friendly 
unit positions and weapons platform availability, location, and status. It is capable of 
supporting both reactive targeting (rapid firing in support of targets that suddenly emerge, 
such as trucks, tanks, troops, etc...) and deliberate targeting (preplanned targets such as 
SAM sites, bridges, enemy C2 nodes). 

LAWS is a PC based system operating in a Windows NT environment (see Figure 
5). LAWS uses two standard monitors for increased information display (vice a single 
display). A standard keyboard and mouse are used for operator input and software 
manipulation. The system is networked over a standard Local Area network (LAN). All 
this is important when it comes to setting up the system. There are no special training 
requirements for setting up LAWS. Any computer specialist familiar with PC’s and 
LAN’s will be able to setup and troubleshoot the system. [Ref. 14] All this equipment is 
COTS (Commercial off the Shelf). 

LAWS displays map data of a particular operating region using standard Defense 
Mapping Agency digital data maps, which is becoming the standard way of loading maps 
into most tactical data systems. All maps are stored on CD-ROM’s, which reduces 
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storage needs. LAWS supports multiple types of map datum which is significant since 
many areas of the world are mapped with different datum. 
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Figure 5. LAWS Architecture and Interface. [Ref. 15] 


LAWS will display unit location and information from a JMCIS feed, LINK 16, 
Advanced Field Artillery Tactical Data Systems (AFATDS) and manual inputs. This 
provides near real time information. The LAWS director can have the operator rapidly 
display the following information: 

• Weapons Available 

• Weapons Platform Location 

• Weapons Status (ready to fire, reloading, gun jammed, etc..) 


34 















• # of munitions remaining for a given ship/platform 

• Range and Bearing from shooter to target 

• Friendly positions (to avoid fratricide) 

All of these windows can be opened simultaneously and provide the LAWS Director with 
all information needed to plan fire missions. All of this information is on the network 
and is automatically updated via various communication links. 

After fire support request are submitted to the SACC, they will perform the 
following functions: 

1. Determine target location from requestor and, if possible augment this 
with imagery from various sources. 

2. Allow operator/LAWS director to determine optimum weapons platform 
to engage target. 

3. Allow operator/LAWS director to determine optimum munitions based on 
availability and number of rounds needed. 

4. LAWS will display all pertinent data in a fire mission request window for 
review 

5. An operator will then send the fire mission order to the selected weapons 
platform 

6. LAWS terminal on the firing platform will respond when the round has 
been fired. 

2. Advanced Field Artillery Tactical Data System (AFATDS) 

AFATDS is a multi-service automated command and control system comprised of 
mobile, multi-functional nodes providing planning and execution capabilities to fire 
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support operational facilities and user centers. [Ref. 16] This system operates at the Fire 
Support Element (FSE), Fire Support Coordination Centers (FSCC) of the supported 
maneuver force, Field Artillery Command Posts (FACP), Fire Direction Centers (FDC), 
Tactical Air Command Centers (TACC), Direct Air Support Centers (DASC), and 
onboard ships. These combined operational elements provide an umbrella of automated 
fire support. AFATDS combines these operational elements into a singular command, 
control, and communications solution to the complex problem of integrating and 
controlling fire support assets. It provides the commander with: 

• Updated Situational Awareness (see Figure 6). 

• Integrated, responsive and reliable fire support. 

• Vastly improved flexibility in providing inputs for items such as 
commander’s criteria and priority of fire information. 

• A distributed database for all systems, which will insure that they all are 
operating with the same information. 

• Ability to attack the right target, using the right weapon system, with the 
right munitions. [Ref. 17] 
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Figure 6. AFATDS Situational Awareness. [Ref. 17] 

The major components of AFATDS are the lightweight computer unit (LCU), a 
90 MHz Intel Pentium processor, with 32 MB of RAM, a 500 MB removable hard drive, 
a 10.4” color LCD, and built in SCSI and Ethernet ports (see Figure 7). It is 
interoperable with the tactical smart modem, and the Tactical Communications Interface 
Module (TCIM). This allows the system continuous communications with all echelons 
via electronic mail and data sharing tools. Built with an open system, nonproprietary 
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architecture, the LCU has the capability to run applications under UNIX, MSDOS, or 
Windows. Standard software includes MSDOS, Microsoft Windows, and Century 
modem communications software. The TCIMs provide a powerful interface for 
computer workstations employed by joint and allied military services. TCIMs allow for 
data transfer to unique military tactical devices used on the emerging digital battlefield. 



Figure?. AFATDS. [Ref. 17] 


Designed for rugged, on the move operations, TCIMs support horizontal and 
vertical interoperability for joint and coalition operations. The TCIM not only supports 
joint systems like JTIDS at rates up to 2 million bps, but also field wire at rates of 
512kbps. Combined with the LCU, this system can interoperate with many forms of 
communications on the battlefield. The software is DISA DII-COE compliant. The 
TCIM works with over 37 types of joint service communications equipment. It meets 
current and evolving interface and protocol standards. Man portable and vehicle 
mounted, the TCIM is a front-end conununications processor that supports joint tactical 
communications for a variety of commercial and military host computers. AFATDS 
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meets existing field artillery tactical data systems standard message formats and 
protocols. It is capable of interoperating with joint services using Joint Variable Message 
Formats (JVMF) or the United States Message Text Formats (USMTF). 

3. Palm Enhanced Linked Virtual Information System (PalmELVIS) 

PalmELVIS is a palmtop client of the Enhanced Linked Virtual Information 
System (ELVIS) n Global Command and Control System (GCCS) Common Operational 
Picture (COP). PalmELVIS provides a palm-sized view of the COP. [Ref. 18] It runs 
on a Palm Pilot HI, made by 3COM, which is the thinnest thin client, rugged and 
versatile, and simple yet powerful. It uses reliable TCP/IP addressing and supports both 
continuous and discontinuous conununications. PalmELVIS provides a COP view that 
displays maps and tracks from GCCS while also providing track updates to GCCS via a 
Global Positioning System (GPS) interface. This small unit also includes the most 
important aspect for this thesis, which is the ability to send call-for-fire messages (see 
Figure 8) and operational notes (OPNOTES). PalmELVIS includes simple decision aids 
that allow for interrogation for amplifying track data, compute range and bearing, and 
support the use of imagery and scanned maps as background. 
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Figure 8. PalmELVIS Call-for-Fire Screen. [Ref. 19] 


PalmELVIS connects to an ELVIS n server via TCP/IP, a LAN, or dial-up. 
ELVIS n is the server that passes information between PalmELVIS and GCCS. ELVIS 
n is Defense Information Infrastructure (DII) Common Operating Environment (COE) 
level five compliant. It is available with GCCS version 3.02 and runs on a GCCS 
workstation. The server interfaces with DII COE for maps, tracks, overlays, ATO, and 
other information and supports group collaboration. [Ref. 19] 
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PalmELVIS peraiits viewing of a portion of the GCCS “tactical picture” in a very 
small box (see Figure 9). The basic meaning of “tactical picture” is a view of friendly 
and enemy units (ships, vehicles, groups of people, etc...) shown on a map of some sort. 


Sample Map Tabs 


[ Flexibility: Each map tab allows a different map and plot control 



ADRG map of Seoul from NIMA Imagery of Seoul Scanned Street Map of Seoul 


International Research Institute, Inc. 


Figure 9. PalmELVIS Mapping. [Ref. 19] 


Marines can use PalmELVIS in the field to view the Common Operational Picture 
near real time on a digitized map screen. It provides a way to see and interact with the 
COP without carrying larger laptops thus improving Marines situational awareness. 
Connected into the fire support network, PalmELVIS achieves the desired capabilities 
and characteristics that the Marine Corps and ONR seek for use in the ELB ACTD ’01. 
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4. Systems Interoperability 

LAWS, AFATDS, and PalmELVIS can pass information and more importantly 
fire support messages between them because of their DII COE compliance. By using the 
JVMF and the USMTF, these systems can pass and process call-for-fire messages. These 
systems are also GCCS compliant and can improve each other’s situational awareness by 
exchanging position reporting and status updates. LAWS and AFATDS interoperability 
has been demonstrated in numerous Fleet Battle Experiments (FBE). 

D. BATTLE EXPERIMENTS 

1. Fleet Battle Experiments 

The Fleet Battle Experiments are a series of experiments directed by the Chief of 
Naval Operations (CNO) to explore and employ emerging systems and technologies and 
develop new concepts in accordance with Joint Vision 2010. Although many concepts 
and technologies were tested, the following discussion is limited to those lessons learned 
pertaining to this thesis. 

a. Fleet Battle Experiment “Alpha” (FEB-A) 

FBE-A used a sea-based Special Purpose Marine Air-Ground Task Force 
(SPMAGTF) employing advanced technology and conducting dispersed operations. The 
Maritime Battle Center, sponsors of the FBEs, wanted to demonstrate sea-based 
command and control of a SPMAGTF engaged in OMFTS. They sought to examine 
command, control, communications, and computers, intelligence, surveillance, and 
reconnaissance (C4ISR) capabilities and requirements for a sea-based Joint Task Force 
Commander. The Battle Center evaluated advanced naval surface fire support employing 
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the arsenal ship and the Naval Surface Fire Support Weapons Control System-Prototype 
(NWCS-P). 

FBE-A successfully demonstrated the “Ring of Fire (ROF)” concept to 
allocate and coordinate calls for fire in a rapid efficient fashion. The ROF concept 
demonstrated the capability of a group of firing platforms, acting on a single network, to 
quickly answer calls for fire. Having immediate access to the status of weapons loadouts 
on all of the firing platforms was a major benefit of the ROF. This superb concept was of 
great value and follow-on studies were conducted in the succeeding FBEs. FBE-A 
demonstrated the sensor-to-shooter concept using the Joint Surveillance Targeting Attack 
Radar System (JSTARS) and the NWCS ROF concept to transmit target information 
directly to weapons platforms. [Ref. 20] 

b. Fleet Battle Experiment “Bravo” (FBE-B) 

FBE-B focused on two specific areas of experimentation: the joint fires 
coordination process ROF and the JTF targeting process for GPS guided munitions 
including supporting C4ISR architecture. For FBE-B, the ROF concept was defined as a 
joint distributive fires network which enables the JTF commander to plan and execute 
fires in the Joint Operations Area (JOA). The Ring of Fire networked artillery, naval 
surface fires, close air support, and deep strike land attack employing a variety of 
weapons. The Navy’s Land Attack Warfare Systems (LAWS) was used as the core of the 
ROF. 

FBE-B’s Ring of Fire effectively executed joint fire missions. Also, it 
successfully demonstrated that the ROF “battle” LAN concept was scaleable to the 
tactical situation, could apply a distributed arsenal of weapons to targets, and respond to 
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high rates of digital calls for fire. LAWS performed well in a benign environment. 
FBE-B demonstrated that LAWS operators can successfully service targets when 
stimulated. The experiment exposed that weapons-target pairing was rudimentary, based 
primarily on time of flight, without regard for priority, protocol, or precise weaponry. 
FBE-B did prove that LAWS was inherently flexible for incorporating advanced 
weapons. LAWS demonstrated a robust automated database for weapons and 
inventories, especially advanced weapons. Finally, the experiment demonstrated that 
AFATDS and J-STARS integration is of particular value in the littoral. AFATDS and J- 
STARS integration enhanced joint interoperability testing. [Ref. 21] 
c. Fleet Battle Experiment “Charlie” (FBE-C) 

FBE-C examined network-centric warfare in the littoral with a focus on 
two conceptual warfare themes: 

• Area Air Defense Commander 

• Ring of Fires (Naval Fires) 

The experiment was divided into two phases. Phase I exarmned the 
planning and execution of the Area Air Defense Commander’s (AADC) for theatre air 
and missile defense in the JOA. Phase B continued experimentation and maturation of 
the Ring of Fire concept conceived and developed in FBE-A&B. 

The FBE-C ROF networked naval surface fires, close air support, and 
deep strike land attack employing a variety of weapons in a simulated environment. 
LAWS once again served as the core of the ROF. Seven LAWS terminals were used in 
the Joint Fires Cell. Building on previous ROF experiments, additional ROF 
experimental factors and LAWS functionalities were added to those of FBE-B. These 
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factors were: greater use and integration of CAS; more robust and better integrated 
LAWS deconfliction tools; more sophisticated target prioritization criteria with regards to 
time latency; improved weapon-target pairing which considered weapons inventory’s as 
well as weapons effects and time to engage; and automatic check fire for No Fire Areas 
(NFAs). 

The experiment re-substantiated that the ROF concept for executing joint 
fire missions and LAWS performance was outstanding. FBE-C also demonstrated that 
the ROF “battle” Wide Area Network (WAN) concept is easily adaptable to a notional 
Joint Fires Cell. It also proved that ROF can manage the near battle inside the Fire 
Support Coordination Lines (FSCLs) as well as deep battles beyond the FSCL and the 
ROF can manage resources in accordance with a JTF Commander’s guidance and firing 
matrix. Finally, FBE-C showed that follow-on ROF should include artillery experiments 
and continue to work on AFATDS-LAWS interoperability. [Ref. 22] 
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IV. SATELLITE CONSTELLATIONS 


A. INTRODUCTION 

Information is becoming increasingly essential to all those things associated with 
quality of life: economic opportunity, education, health care, and public services. Yet, 
most people in the world today do not have access to the most basic telephone service. To 
cite just one statistic, more than half the world’s population hves more than two hours’ 
travel time from the nearest telephone. The high cost of wireline infrastructure has often 
kept telecommunications services from remote areas. Vast regions of the developing 
world are completely without telephone service. India has 900 million people but only 
about seven million telephone lines, virtually all of them clustered in a few large cities. 
Where basic telephone service is available, the networks over which it is provided consist 
of 100-year-old technology - analog signals on copper wire - that for the overwhelming 
part will never be upgraded to the digital, broadband capability required for the advanced 
network connections that have come to be known as the information superhighway. 
Using the most optimistic estimates of costs per mile, there is little possibility that any 
developing nation will be able to fund the engineering effort that created the existing 
terrestrial wireline networks of Europe and North America. Even in developed countries, 
there is a risk that rural areas and populations will be denied access to the powerful 
digital technologies that are changing the world. [Ref. 24] Three low earth orbit (LEO) 
based systems. Iridium, Teledesic, and Globalstar, were formed with the objective of 
creating a means of providing affordable access to advanced network connections to all 
parts of the world that will never receive such advanced capabilities through existing 
technologies. [Ref. 25] 
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These LEO systems each focused on a different service segment and a different 
portion of the radio frequency spectrum. The best way of distinguishing between these 
three LEO system types is by reference to their corresponding terrestrial (land-line) 
services: 

• "Little LEOs," like OrbComm, are the satellite equivalent of paging. They 
operate below 1 GHz, and provide simple store-and-forward messaging. These systems 
offer low data rates but can provide valuable services in a wide range of settings, such as 
remote monitoring and vehicle tracking. 

• "Big LEOs" like Iridium, Globalstar and ICO, have received the most attention. 
They are the satellite equivalent of cellular phone service, and operate between 1 and 3 
GHz. 

• Teledesic is the first proposed "broadband LEO." It will provide the satellite 
equivalent to optical fiber. Because it will operate in the Ka band, essentially line-of-sight 
from the user terminal to the satellite is required, which makes it more appropriate for 
fixed applications, or mobile applications like maritime and aviation use, where line-of- 
sight is not an issue. It will provide the advanced, digital broadband network connections 
to all those parts of the world that are not likely to get those capabilities through wireline 
means. [Ref. 26] 

B. IRIDIUM 

Iridium, a “Big LEO”, will be the first major constellation to actually provide 
service to customers. Iridium services will become the ultimate solution to wireless 
communications and worldwide connectivity. The Iridium system (see Figure 10) 
promises to offer access to dial tone virtually anywhere on earth. By the year-end 2000, 
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the number of cellular subscribers worldwide is expected to reach 295 million, along with 
160 million paging subscribers. Iridium, Inc. anticipates serving 650,000 voice and 
350,000 paging subscribers worldwide in 2000. For undeveloped areas where telephone 
systems infrastructure costs have been prohibitive, the Iridium system provides 
governments and telecommunications providers with either an economical alternative or 
an interim service. 



Figure 10. Iridium Architecture. [Ref. 26] 


Based in Washington D.C., Iridium is a satellite-based, wireless personal 
co mmuni cations network designed to permit any type of telephone transmission to reach 
its destination anywhere on earth. The Iridium system was conceived in 1987 by 
engineers at Motorola’s Satellite Communications Division. With the goal of providing 
truly global coverage, engineers determined that the system would require a constellation 
of low earth orbiting (LEO) satellites. The satellites would be relatively small and simply 
constructed so they could be built, launched and replaced economically. 
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Market analyses conducted by Motorola determined the requirements for system capacity 
and financing. A strong potential market was identified for a system that would provide 
high quality service at reasonable rates. [Ref. 27] 

Iridium will bring a new dimension of capability to the commercial, rural and 
mobile areas by providing universal, portable service. Subscribers will use wireless, 
pocket-sized Iridium telephones, transmitting through digital facilities, to communicate 
with any other telephone in the world. Unlike regular telecommunication networks, the 
66 satellite system will track the location of the telephone handset, providing global 
transmission even if the subscriber’s location is unknown. In areas where cellular service 
is available, the dual mode phone will provide the option of transmitting a call through 
the cellular system. For the first time in history, individuals will soon have the ability to 
use one telephone to make or receive calls from anywhere on the planet. 

Iridium is an international consortium of leading telecommunications and 
industrial companies that owns the satellite constellation and is responsible for providing 
the funding for the construction and implementation of the Iridium system. In addition, 
this company is responsible for network operations, standards and operating practices, 
and corporate relations. 

1. Satellite Characteristics 

Iridium’s network of satellites will orbit the earth at a height of 413 nautical 
miles, ensuring that every point on the earth’s surface is in continuous line of sight with 
one of the satellites. The satellites will be deployed in six circular polar orbits, with 11 
satellites per plane. Each satellite in the constellation is connected by radio transmission 
to four others making it possible to hand off calls between satellites in the same or 
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adjacent orbiting planes. The satellites (see Figure 11) are lightweight, approximately 725 
kilograms and have an expected lifespan of five to six years. They are considered "smart" 
because they can switch and route calls in space. Each satellite antenna pattern will 
project 48 cells onto the earth’s surface. Each cell will provide communications coverage 
for an area of the earth’s surface roughly 350 nautical miles in diameter; people will 
communicate with the satellites using equipment operating at frequencies of 1.5/1.6 
gigahertz, just above land-based cellular radiotelephones. In addition to voice, the digital 
system can transmit data at a rate of 2400 baud. [Ref. 27] 



Figure 11. Iridium Satellite. [Ref. 26] 
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2. Iridium Gateways 

Another key component of the system will be a network of "gateway" surface 
facilities in various countries that will link Iridium with the public switched telephone 
network (PSTN). This makes communications between Iridium telephones and any other 
telephone in the world possible. These gateways will store customer billing information 
and will constantly keep track of each user’s location. An Iridium system control facility 
will maintain the satellite network and the overall operation of the system. [Ref. 29] 

3. Communication Links 

The Iridium system will employ a combination of Frequency Division Multiple 
Access and Time Division Multiple Access (FDMA/TDMA) signal multiplexing to make 
the most efficient use of limited spectrum. The following is a list of the communication 
links the Iridium system will use: 

•Mobile L-Band Service links 

Downlinks 1610-1626.5 MHz, L-Band 

Uplinks 1610-1626.5 MHz 

•Intersatellite Links 23.18-23.38 GHz, Ka-Band 

•Gateway/TT&C Links 

Downlinks 19.4-19.6 GHz, Ka-Band 

Uplinks 29.1-29.3 GHz, Ka-Band 

4. Subscriber Units 

The Subscriber units (see Figure 12) are similar to Motorola’s original cellular 
radiotelephones and will offer additional features such as latitude, longitude, altitude and 
Greenwich Mean Time. In addition to the lightweight portables. Iridium subscriber units 
will be available as mobiles or small fixed units. The Iridium system will support 
millions of users worldwide, with a total capacity more than 10 times greater than current 
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geosynchronous satellite systems. The following is a brief description of each type of 
subscriber unit available: 



Figure 12. Iridium Subscriber Units. [Ref. 29] 


Iridium Handheld Telephone 

• Dual-mode: satellite and terrestrial wireless compatible 

• Digital voice: includes data port for transmitting facsimile and computer 
files 

• Transmission rates: voice (Full-duplex, 2.4 Kilobits/sec); data (2400 
baud) 

• Modulation: QPSK with Frequency Division/Time Division Multiple 
Access (FDMA/TDMA) 

• Similar design to Motorola cellular phone 

• Uses digital facilities for maximum clarity and signal quality 

• Batteries: 1 hour talk time and 24 hours of standby time 

Iridium Pager 

• Capable of receiving 66 character alphanumeric messages 

• Message display available in international character set 

• Off the shelf disposable battery: one month lifetime 
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5. 


Iridium Launch Services 


Launching upwards of 66 space vehicles to build a satellite constellation requires 
more than one launch vehicle. Motorola’s Satellite Communications Group chose to 
distribute its launch program among three vehicles to ensure continuing access to space 
and reduce the risk of delay. The Iridium satellite launch vehicles are among the world’s 
most proven and reliable, but their different physical sizes, payload capabilities, flight 
characteristics, and interfaces preclude consideration of a single system for deploying the 
Iridium satellites into low Earth orbit. [Ref. 26] 

a. The Proton 

A state-owned aerospace engineering and manufacturing company in the 
Russian Federation, Khrunichev State Research and Production Space Center did provide 
launch services using three Proton rockets to loft 21 of the 66 operating satellites. The 
Proton launch vehicle is the largest of the three rockets that the Iridium system will use to 
deploy its constellation. It has the capacity to place seven Iridium satellites directly into a 
circular transfer orbit at 512 km (317 miles), where the satellites will be deployed from 
the dispenser. Proton launches are scheduled to take place at the Baikonur launch facility 
in Kazakhstan. [Ref. 27] 

b. The Delta II 

The first launch of Iridium satellites, was from Vandenberg Air Force 
Base in California, USA aboard a Delta n rocket built by McDonnell Douglas. The 
rocket carried five Iridium satellites in the first launch and carried five satellites in each 
of the eight scheduled subsequent launches, eventually deploying 40 of the 66 operational 
satellites. In addition to a new satellite dispenser, capable of deploying 5 satellites 
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simultaneously, the Delta also features a new composite payload fairing. In the past all of 
McDonnell Douglas’ fairings had been more of a classical aerospace structure of 
al uminum, skins, and ribs. However, McDonnell Douglas saw an opportunity with 
multiple launches to develop a new composite fairing that increases performance for the 
rocket and reduces both the manufacturing costs and the cycle time producing the 
hardware. [Ref. 27] 

c. The Long March 2C/SD 

The Long March 2C/SD rocket, built by China Great Wall Industry 
Corporation, launches Iridium satellites two at a time into orbit from the Taiyuan Satellite 
Launch Center in China. The modified Long March 2C rocket with a Smart Dispenser 
(hence Long March-2C/SD) was built specifically for the Iridium system. Launch 
rehearsals, known as Pathfinder exercises, were conducted in 1996. A Long March 2C 
rocket had been previously transported from the China Academy of Launch Technology 
in Beijing to the Taiyuan Satellite Launch Center, which is located 400 miles southwest. 
The Pathfinder exercises included dummy fueling, mating onto the dispenser, and 
interface checks with the launch vehicle. [Ref. 27] 

C. TELEDESIC 

The Teledesic Network (see Figure 14) is a high-capacity broadband network that 
combines the global coverage and low latency of a low-Earth-orbit constellation of 
satellites, the flexibility and robusmess of the Internet, and "fiber-like" quality of service. 
Essentially an "Intemet-in-the Sky," the Teledesic Network will be the first satellite 
system that can handle any kind of communication, from voice calls to Internet browsing 
to video and interactive multimedia. The Teledesic Network can serve as the access link 
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between a user and a gateway into a terrestrial network, or as the means to link users or 
networks together. Covering nearly 100 percent of the Earth’s population and 95 percent 
of the landmass, the Teledesic Network is designed to support millions of simultaneous 
users. [Ref. 28] 

The Teledesic Corporation was founded in 1990 and is headquartered in Kirkland, 
Washington. Principal shareholders are its Chairman and CEO, Craig McCaw, the 
founder of McCaw Cellular Communications which was the world’s largest cellular 
communications company before its 1994 merger with AT&T, and William H. Gates HI, 
the co-founder. Chairman and CEO of Microsoft Corporation, the world’s largest 
computer software company. [Ref. 29] At the 1995 World Radio Conference, Teledesic 
received support to form a new international satellite service designation for the 
frequencies necessary to accommodate the Teledesic Network. The lowest frequency 
band with sufficient spectrum to meet Teledesic’s wideband service, quality and capacity 
objectives is the Ka-band. The terminal-satellite conununication links operate within the 
portion of the Ka frequency band that has been identified internationally for non¬ 
geostationary fixed service. Teledesic was also successful in obtaining a similar 
designation from the US Federal Communication Commission (FCC). Li March 1997, 
the FCC licensed Teledesic to build, launch, and operate the Teledesic Network. [Ref. 
30] 

In April 1997, Teledesic announced that The Boeing Company would become an 
equity partner in Teledesic and serve as the prime contractor for the company’s global, 
broadband "Intemet-in-the-Sky." Boeing would invest up to $100 million for 10 percent 
of the current ownership of Teledesic. Teledesic’s credibility was further boosted by a 
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new plan, presented by Boeing, to reduce the number of satellites in the network to 288 
and place them in a higher orbit than was projected in an original 840 satellite plan. 
Teledesic plans on drawing on the core competencies of Boeing, which include large- 
scale systems integration, software development and launch services. [Ref. 31] 

A test satellite for the Teledesic system was launched in February 1998. Dubbed 
the Tl, it marks the first successful orbit of a commercial, Ka-band low earth orbit 
satellite. Teledesic plans to begin launching operational satellites in the year 2002 with 
service beginning the following year. Initially, Teledesic does not intend to market 
services directly to end-users. Rather, it will provide an open network for the delivery of 
such services by others. The Teledesic Network will enable local telephone companies 
and government authorities in host countries to extend their networks, both in terms of 
geographical area and in the kinds of services they can offer. Ground-based gateways will 
enable service providers to offer seamless links to other wireline and wireless networks. 
[Ref. 32] 

The latest major development occurred on May 21, 1998 when Motorola Inc. 
invested roughly $750 million into Teledesic in return for a 26 percent share in the 
system, replacing Boeing as the prime contractor. While being replaced as the prime 
contractor, Boeing remains part of the development partnership of Teledesic. Motorola 
will combine technical efforts already imder way on the Teledesic system with those 
planned for their proposed Celestri system, which has now been abandoned and its 
concepts merged into the Teledesic system. Teledesic also plans to draw on its 
partnership with Matra Marconi Space’s expertise in satellite bus manufacturing, which 
claims to be able to build a Teledesic satellite in an astounding four days. [Ref. 33] 
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Teledesic’s engineering effort builds on previous work done in many advanced 
commercial and government satellite programs and was assisted by several government 
laboratories. The Teledesic system utilizes proven technology and experience from many 
U.S. defense programs, such as the Strategic Defense Initiative (SDI) project "Brilliant 
Pebbles," which was conceived as a similar orbiting global constellation of 1,000 small, 
advanced, semi-autonomous, interconnected satellites. Since 1990, Teledesic has drawn 
on the expertise of the contractors on that and many other programs for input into the 
early system design activities. [Ref. 30] 

Design, construction, and deployment costs of the Teledesic network are 
estimated at 9 billion dollars. The Teledesic satellites and their associated subsystems 
will be designed and built in quantities large enough to be mass-produced and tested. In 
geostationary systems, any single satellite loss or failure is catastrophic to the system. To 
reduce this contingency to acceptable levels, reliability can be built into the network 
rather than the individual unit, reducing the complexity and cost of the individual 
satellites and enabling more streamlined, automated manufacturing processes and 
associated design enhancements. In its distributed architecture, dynamic routing, and 
scalability, the Teledesic Network emulates the Internet, while adding the benefits of 
real-time capability location-insensitive access. [Ref. 34] 

1. System Architecture Requirements 

To ensure seamless compatibility with terrestrial communication networks, a 
satellite system must be designed with the same essential characteristics as a fiber optic 
network. Communications satellite systems are of two general types: geostationary-Earth- 
orbit (GEO) and non-geostationary, primarily low-Earth-orbit (LEO). GEO satellite 
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systems orbit at an altitude of 41,164 km above the equator, the only orbit that allows the 
satellite to maintain a fixed position in relation to Earth. At this height, communications 
through GEOs (which can travel only as fast as the speed of light) entail a round-trip 
transmission delay of at least one-half second. This GEO latency is the source of the 
annoying delay in many intercontinental phone calls, impeding understanding and 
distorting speech. What can be an inconvenience on voice transmissions, however, can be 
untenable for real-time applications such as videoconferencing as well as many standard 
data protocols. This means that GEOs can never provide fiber-like quality needed for 
some applications, especially the protocols of the Internet. [Ref. 35] 

GEO satellite communications systems require changes to terrestrial network 
standards and protocols to accommodate their inherent high latency. In contrast, 
Teledesic’s objective is to meet current network standards rather than to change them. By 
using fiber-optic as the guideline for service quality, the Teledesic Network is designed 
for compatibility with applications that are based on the networking protocols of today 
and tomorrow. This places stringent requirements on the system design, including low 
latency, low error rates, high service availability, and flexible, broadband capacity - all 
characteristics of fiber. The advanced digital broadband networks will be packet-switched 
networks in which voice, video, and data are all just packets of digitized bits. It is not 
feasible to separate out applications that can tolerate delay from those that can't. As a 
result, the network has to be designed for the most demanding application. [Ref. 34] 
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2 . 


Orbit and Constellation 


Teledesic plans to alleviate the known GEO communication problems with a huge 
LEO satellite constellation. Latency is a critical parameter of communication service 
quality, particularly for interactive communication and for many standard data protocols. 
To be compatible with the latency requirements of protocols developed for the terrestrial 
broadband infrastructure, Teledesic satellites will orbit at low altitude, under 1,400 
kilometers. Downlinks will transmit between 18.8 GHz and 19.3 GHz, and uplinks will 
operate between 28.6 GHz and 29.1 GHz. Communication links at these frequencies are 
degraded by rain and blocked by obstacles in the line-of-sight. To avoid obstacles and 
limit the portion of the signal path exposed to rain requires that the satellite serving a 
terminal be at a high elevation angle above the horizon. The Teledesic constellation 
guarantees a minimum elevation angle of 40° within its entire service area. [Ref. 34] 

The combination of high mask angle and low-Earth-orbit result in a relatively 
small satellite coverage zone, or footprint, that enables efficient spectrum re-use but 
requires a large number of satellites to serve the entire Earth. In the initial constellation, 
the Teledesic Network will consist of 288 operational satellites, divided into 12 planes, 
each with 24 satellites. The altitudes of satellites in different orbit planes are staggered to 
eliminate the possibility of collision between satellites in crossing orbits. Once the 
satellites are aloft they will circle in a polar orbit from north to south. The orbit planes are 
at a sun-S5mchronous inclination (approximately 98.2°), which keeps them at a constant 
relative angle to the sun. [Ref. 28] 
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3. Space Segment 

The Teledesic satellites are complex, employing state-of-the-art technologies such 
as inter-satellite links, phased array antennas, advanced battery cells, and gallium 
arsenide integrated circuits. An underlying goal in their design is high volume production 
and test processes. On orbit, the satellites will operate with a high degree of autonomy, 
with on-board systems for orbit determination, navigation, and health monitoring. Each 
satellite monitors its status and periodically sends reports on its vital functions to the 
Constellation Operations Control Centers (COCC). Exception conditions are reported 
immediately. The COCC sends commands to the satellite and its subsystems as necessary 
in response to exception conditions. Figure 13. illustrates the satellite’s on orbit 
configuration. [Ref. 38] 



Figure 13. Teledesic Satellite. [Ref. 36] 


On-board processing will be accomplished through the command and data 
handling subsystem (C&DH), consisting of multiple high-speed microprocessors, a high- 
capacity solid-state random access memory (RAM), a LAN for connection with other bus 
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components, as well as an engineering diagnostic and trending (HDAT) processor. The 
rectangular baseplate supports eight pairs of inter-satellite link antennas, three large 
electronically steered phased-array antenna panels, the two satellite bus structures that 
house the engineering subsystem components, and propulsion thrusters. A third satellite 
bus structure will contain the power equipment and additional thrusters. The attitude and 
orbit determination and control (AODC) subsystem will use acquisition sun sensors to 
orient the satellite inunediately after orbit insertion and inertial measuring units, 
magnetometers, and precision microwave nadir-pointing information for attitude sensing 
afterward. Satellite attitude will be maintained in all three axes to within 0.2 degrees via 
magnetic torque and reaction wheels. The electronic beam steering of the antenna will 
have an accuracy of 0.1 degree. Stationkeeping and other orbit maneuvers will be 
performed using redundant low-thrust electric powered thrusters, which have a AV 
budget in excess of 1000 m/s. Thermal control will be semipassive using a combination 
of thermal blankets and paint for bus elements and phase-change thermal capacitors and 
heat pipe devices for the payload. Batteries will allow full payload operation during 
eclipse periods. [Ref. 36] 

The estimated on-orbit lifetime of each satellite is 10 years. Degradables and 
consumables (i.e., solar array, batteries, propellant, etc.) have been sized to exceed the 10 
year lifetime. Each satellite carries over twice the propellant needed to insert itself into its 
orbital position, to overcome any minor atmospheric drag, to reposition itself when 
required, and to perform a final deorbit maneuver. [Ref. 36] 
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4. Communications Payload 

The communications payload is the heart of the Teledesic satelhte and is centered 
around the fast packet switch (FPS). This switch is responsible for routing data packets 
to and from the Scanning Beam (SB) subsystem, the Gigalink Satellite link (GSL) 
subsystem and the Inter-Satellite Link (ISL) subsystem. The FPS is essentially non- 
blocking with very low packet delay, and has a throughput in excess of 5 Gbps. Each 
subsystem consists of an active element phased array antenna for transmitting and 
receiving signals. For the transmit side, all data packets received from the FPS are 
encoded and modulated to form an IF signal which is then upconverted and applied to the 
particular array. The antenna converts RF signals to a free-space propagated waveform 
with the proper polarization for the Earth-fixed cell or satellite it is serving. The receive 
side operates in a similar manner but in the opposite direction. The SB subsystem is 
responsible for scanning the corresponding Earth-fixed cell the satellite is currently 
serving. As the satellite movement causes a cell to pass out of view of one array and into 
the view of the next, coverage responsibility is passed from one array to the next. The 
FPS routes packets addressed to a user terminal within the satellite’s coverage zone to the 
SB antenna currently serving that cell. The GSL subsystem operates similarly to the SB 
system but serves the ground-based GigaLink terminals in its corresponding cell. The ISL 
subsystem uses its array to communicate with the eight adjacent satellites in the 
constellation. All signals are pre-compensated to eliminate the apparent Doppler shift due 
to the satellite’s movement. A frequency reference subsystem provides stable frequency 
and time reference to the SB, GSL, and ISL subsystems while a computer subsystem 
provides control information to the FPS and SB, GSL, and ISL subsystems. [Ref. 36] 
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5. Launch Segment 

The Teledesic satellite is specifically designed to take advantage of the economies 
that result from high volume production and launch. To minimize launch costs and the 
deployment interval, the satellites are designed to be compatible with over twenty 
existing international launch systems, and to be stacked so that multiple satellites can be 
launched on a single vehicle. Teledesic plans to use a combination of existing domestic 
and international launch vehicles to deploy the initial constellation, including on-orbit 
spares, over a two-year period. Individual satellites, the constellation as a whole, and the 
COCCs are designed to operate with a high degree of autonomy. The initial constellation 
includes a number of active on-orbit spares that can be used to "repair" the network 
immediately if a satellite is removed from service temporarily or permanently. Routine 
periodic launches will be used to maintain appropriate levels of spares in each orbit 
plane. Launch vehicles and satellites that have reached the end of their useful life are 
deorbited. They disintegrate harmlessly on re-entry, and will not create space debris. 
[Ref. 28] 

6. Ground Segment 

The Teledesic ground segment consists of terminals, network GigaLink gateways 
and network operations and control systems. Terminals are the hub of the Teledesic 
Network and provide the interface both between the satellite network and the terrestrial 
end-users and networks. They perform the translation between the Teledesic Network’s 
internal protocols and the standard protocols of the terrestrial world, thus isolating the 
satellite-based core network from complexity and change. [Ref. 34] 
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Teledesic terminals communicate directly with the satellite network and support a 
wide range of data rates. The terminals also interface with a wide range of standard 
network protocols, including IP, ISDN, ATM, and others. Although optimized for service 
to fixed-site terminals, the Teledesic Network is able to serve transportable and mobile 
terminals, such as those for maritime and aviation applications pief. 28]. These terminals 
can use antennas with diameters from 16 cm to 1.8 m as determined by the terminals’ 
rnaximiim transmit channel rate, climatic region, and availability requirements. Their 
average transmit power will vary from less than 0.01 W to 4.7 W. [Ref. 37] The 
Teledesic terminals will provide the interconnection points for the Teledesic Network’s 
Constellation Operations Control Centers and Network Operations Control Centers 
(NOCC). COCCs coordinate initial deployment of the satellites, replenishment of spares, 
fault diagnosis, repair, and de-orbiting. The autonomous design of Teledesic satellites 
minimizes the required telemetry, tracking and command communication required from 
the COCCs. The satellites report exception conditions immediately and periodically send 
status reports on vital functions to the COCCs. The NOCCs include a variety of 
distributed network administration and control functions including network databases, 
feature processors, network management and billing systems. [Ref. 34] GigaLink 
Terminals provide gateway connections to public networks and to Teledesic support and 
database systems including NOCCs and COCCs, as well as to privately owned networks 
and high-rate terminals. A satellite can support up to sixteen GigaLink Terminals within 
its service area. [Ref. 37] 
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7. Network Operations 

The Teledesic Network (see Figure 14) is a dynamic constellation of a minimum 
of 288 identical operating satellites. Each satellite functions as a communications node of 
equal rank and importance that is linked to its eight closest neighbors and independently 
handles traffic without ground control. The degree of autonomy with which each satellite 
operates represents a significant advance in space technology. The on-board orbit 
determination and navigation subsystem developed by Teledesic represents an innovation 
that significantly advances the state-of-the-art of LEO satellite telecommunications. Each 
satellite continuously and autonomously determines its own position and attitude, and 
maintains its position within the constellation by adjusting its attitude and position within 
the orbit plane. The orbit determination and navigation subsystem employs ranging 
between satellites and to points on the earth’s surface as a reference to determine and 
maintain the satellite’s position. This precision position information is used to select the 
optimum path for routing packets among the satellites in the constellation. It is also used 
to steer the phased-array antennas to the Earth-fixed cell grid and to neighboring 
satellites. In addition, each satellite continuously monitors its own health and analyzes 
trends to project future problems. The high degree of system autonomy assures network 
integrity and enhances its efficiency, thereby reducing costs. [Ref 36] 

Teledesic has designed its system using an Earth-fixed cell design to avoid the 
"hand-off inefficiencies and service interruption that would result if the small cell 
pattern swept over the Earth at the velocity of the satellite footprint. Teledesic’s proposal 
represents the first application of this innovative feature for a commercial LEO satellite 
system. Teledesic cells and their associated communication channel resources are 
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organized in an Earth-fixed grid. As a satellite passes over the fixed cell, the satellite 
steers its antenna beams to the fixed cell locations within its coverage area. This allows a 
terminal to maintain the same channel assignment even though it may be served by 
several different beams and satellites during a call. This concept maximizes frequency 
reuse and system capacity and minimizes processing costs and frequency management 
problems. As a result, Teledesic’s system reuses spectrum over 350 times within the 
United States and over 20,000 times worldwide. This concept also allows Teledesic to 
contour its service offering to geographical boundaries, which is difficult to accomplish 
with large cells that move with the satellite. [Ref. 36] 
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Figure 14. Teledesic Network. [Ref. 34] 
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8. Communications Architecture 

The Teledesic Network uses fast packet switching technology based on the 
Asynchronous Transfer Mode (ATM) technology now being used in Local Area 
Networks (LAN), Wide Area Networks (WAN), and the Broadband Integrated Services 
Digital Network (B-ISDN). All communication is treated identically within the network 
as streams of short fixed-length packets. Each packet contains a header that includes 
address and sequence information, an error-control section used to verify the integrity of 
the header, and a payload section that carries the digitally encoded voice or data. 
Conversion to and from the packet format takes place in the ground-based terminals. The 
fast packet switch network also combines the advantages of a circuit-switched network 
(low delay digital pipes), and a packet-switched network (efficient handling of multi-rate 
data). Fast packet switching technology is ideally suited for the dynamic nature of a LEO 
network. [Ref. 37] 

Each satellite in the constellation is a node in Teledesic’s fast packet switch 
network, and has inter-satellite communication links with eight adjacent satellites. This 
interconnection arrangement forms a non-hierarchical "geodesic," or mesh, network and 
provides a robust network configuration that is tolerant to fault and local congestion [Ref. 
39]. In hierarchical systems, when a node or link fails, service for entire sections of the 
network may be disrupted. In contrast, the Teledesic Network’s high coverage 
redundancy, rich connectivity, and autonomous adaptive packet-routing capability limit 
or eliminate the effect of the failure of a node or link. Adjacent spacecraft in the web 
share the workload of their disabled neighbor, until it can be repaired or replaced by an 
on-orbit spare, while maintaining a constant level and quality of service. [Ref. 30] 
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The topology of this 288 satellite LEO constellation is dynamic. Each satelhte 
keeps the same relative position relative to other satellites in its orbital plane. Its position 
and propagation delay relative to earth terminals and to satellites in other planes changes 
continuously and predictably. In addition to changes in network topology, as traffic flows 
through the network, queues of packets accumulate in the satellites, changing the waiting 
time before transmission to the next satellite. All of these factors affect the packet routing 
choice made by the fast packet switch in each satellite. These decisions are made 
continuously by a microprocessor within each satellite node using Teledesic’s distributed 
adaptive routing algorithm. This routing algorithm adapts the packet routing decisions to 
the current network configuration and to the mapping between satellite scanning beams 
and fixed cells on Earth. The algorithm uses information broadcast throughout the 
network by each satellite to learn the current status of the network and to select the path 
of least delay to route each packet to its destination. The algorithm also controls the 
connection and disconnection of network inter-satellite links. [Ref. 30] 

The network uses a "connectionless" protocol, using a combination of destination- 
based packet addressing and a distributed, adaptive packet routing algorithm to achieve 
low delay variability across the network. Each packet carries the network address of the 
destination terminal, and each node independently selects the least-delay route to that 
destination. Packets of the same session may follow different paths through the network. 
[Ref. 30] The required packets are buffered, and if necessary resequenced, at the 
destination terminal to eliminate the effect of timing variations. Teledesic has performed 
extensive and detailed simulation of the network and adaptive routing algorithm to verify 
that they meet Teledesic’s network delay and delay variability requirements. [Ref. 28] 


69 


Teledesic’s network-control software, fast-packet switch architecture and richly 
inter-connected network provide many possible pathways through the network for each 
individual packet. This provides a degree of security and assurance previously 
unavailable. In essence, the system reliability is built into the constellation as a whole 
rather than being vulnerable to the failure of a single satellite. To achieve high system 
capacity and channel density, each satellite is able to concentrate a large amount of 
capacity in its relatively small coverage area. Overlapping coverage area plus the use of 
on-orbit spares permit the rapid repair of the network whenever a satellite failure results 
in a coverage gap. [Ref. 36] 

The Teledesic Network will provide a quality of service comparable to today’s 
modem terrestrial communication systems, with bit error rates less than 10'®, and a link 
availability of 99.9 percent over most of the United States. The 16 kbps basic channel 
rate supports low-delay voice coding that meets "network quality" standards. The 
Network will offer high-capacity, "bandwidth-on-demand" through standard user 
terminals. Channel bandwidths range from a minimum of 16 kbps up to 2.048 Mbps (El) 
on the uplink, and up to 28 Mbps on the downlink. Teledesic also will be able to provide 
a smaller number of high-rate channels at 155 Mbps to 1.24416 Gbps (OC-24) for 
gateway connections and users with special applications. Most users will have two-way 
wideband terminal connections that provide up to 64 Mbps on the downlink and up to 2 
Mbps on the uplink. This represents access speeds up to 2,000 times faster than today’s 
standard analog modems. The low orbit and high frequency allow the use of small, low 
power terminals and antennas, with a cost comparable to that of a notebook computer. 
[Ref. 28] 
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Teledesic will use the small, earth-fixed cells both for efficient spectrum 
utilization and to respect countries’ territorial boundaries. Within a 53 by 53 km cell, the 
Network will be able to accommodate over 1800 simultaneous 16 kbps voice channels, 
14 simultaneous El channels, or any comparable combination of channel bandwidths. 
The Teledesic Network is designed to support a peak capacity of 1,000,000 full-duplex 
El connections, and a sustained capacity sufficient to support millions of simultaneous 
users. The system design also allows a graceful evolution to constellations with much 
higher capacity without altering the system architecture, spectrum plan, or user terminals. 
The network capacity estimates assume a realistic, non-uniform distribution pattern of 
users over the Earth’s land masses. Some cells will generate over 100 times the traffic of 
the "average" cell. [Ref. 38] 

The ability to handle multiple channel rates, protocols and service priorities 
provides the flexibility to support a wide range of applications including the Internet, 
corporate Intranets, multimedia communication, LAN interconnect, etc. In fact, flexibility 
is a critical network feature, since many of the applications and protocols Teledesic will 
serve in the future have not yet been conceived. 

D. GLOBALSTAR 

On 9 September 1998, Globalstar, Qualcomm and Telecommunications par 
Satellites Mobiles (TE.SA.M.) proudly conducted their first public Globalstar phone call 
at the sixth Satel Conseil Symposium in Paris, France [Ref. 39]. While Globalstar 
officials were lauding this accomplishment, however, a disaster was about to occur across 
the continent. That same day, a Russian Zenit-2 rocket exploded shortly after launch 
from the Baikonur cosmodrome, destroying 12 Globalstar satellites [Ref. 40]. Although 
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the satellites lost were fully insured, Globalstar experienced a large setback in its timeline 
to begin service with all 48 satellites in orbit. This was a particularly disappointing event 
considering that Iridium, Globalstar’s closest competitor, already had its entire 
constellation in orbit [Ref. 41]. Globalstar now intends to begin service by the end of 
1999 with only 32 satellites in orbit, filling the remainder of the constellation with 
subsequent launches. 

1. Orbit and Constellation 

The Globalstar system will utilize a total of 48 operational satellites placed in 
eight orbital planes. This will provide continuous service coverage firom 70 degrees 
South latitude to 70 degrees North latitude. 

a. Constellation Geometry 

The Globalstar satellites will reside in what is known as a Walker 
constellation, or 48/8/1/52 degrees/1389, (48 satellites, uniformly distributed in eight 
planes, with a phase shift of 7.5degrees from one plane to another, inclination 52 degs. 
and altitude 1389 km [Ref. 42]), as depicted in Figure 15. 
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Figure 15. Globalstar Constellation. [Ref. 43] 


b. Constellation Effectiveness 

The Walker constellation was chosen for its world-wide coverage, from 0 
to 70 degrees latitude. While this geometry does provide for “world-wide” coverage, it 
does not provide “global coverage,” 0 to 90 degrees latitude, like its greatest competitor. 
Motorola’s Iridium. To provide its “global coverage,” the Iridium system will utilize 
polar orbits and require a total of 66 satelhtes. While this is a tradeoff in performance for 
Globalstar, it will provide a cost-cutting measure for Globalstar service. 

The large number of satellites per orbital plane will provide high average 
elevation angles and in turn produce the propagation margins required for mobile 
communications. Additionally, the low altitude nature of its LEO system provides a 
variety of other benefits to this venture. First, the satellites can be placed in orbit by a 
wide variety of launch vehicles, as discussed earlier. Secondly, the power required to 
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reach a LEO satellite by a ground user is substantially less than reaching a geostationary 
satellite, for example. This allows for the user to place the transmitter/phone next to the 
ear without fear of harmful physiological effects and also allows for the use of a much 
smaller transmitter/receiver antenna. A third advantage of LEO orbits is the near real 
time transmission of data, precluding the delays and echoes experienced in geostationary 
communication systems. Lastly, LEO systems provide a far greater degree of 
redundancy through their large number of satellites, whereas geostationary systems can 
become useless with the loss of just one satellite. 

2. Space Segment 

The space segment of the space mission architecture includes both the satellite 
bus and its payload. The bus provides services, such as orbit and attitude maintenance, 
power, structure, data handling, and climate control, while the payload contributes those 
items required for interaction with the user [Ref. 44]. The mass of a Globalstar satellite 
(see Figure 16.) is approximately 450 kg, and the first generation spacecraft are designed 
to operate at full performance for 7 1/2 years, 
a. Spacecraft Bus 

The trapezoidal shape of the satellite helps to conserve volume and allows 
for the mounting of several spacecraft within the fairing of the launch vehicle. The 
Globalstar satellites are stabilized with a three-axis attitude control system, and are some 
of the first satellites to utilize Global Positioning System (GPS) for tracking orbital 
position and attitude. Most attitude control functions are accomplished through 
momentum wheels and magnetic torquers, with the five thrusters used primarily for orbit 
raising and maneuvering. 
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Figure 16. Globalstar Satellite. [Ref. 43] 

The satellite receives its power through two 155-inch long solar arrays. 
The solar arrays also feed batteries to provide power when the sun is not available or 
eclipsed. The solar panels are designed to provide 1,100 W of power and automatically 
adjust to provide ma ximum sun exposure. While the satellites do transfer information to 
and from the ground, no onboard processing is done. This “bent-pipe” design maintains a 
low-cost satellite architecture, which is extremely important considering that 48 
spacecraft will be utilized in the Globalstar constellation. [Ref. 43] 
b. Spacecraft Payload 

The payload of the Globalstar satellite, communications equipment, is 
mounted to the bus’s Earth deck. The payload consists of C-band antennas, for 
communicating with Globalstar’s Gateways, and L- and S-band antennas for 
communicating with user terminals. These phased array antennas project 16 beams on 
the Earth’s surface, providing a service footprint several kilometers in diameter. [Ref. 43] 


75 












3. Launch Segment 

Although the launch segment of a space mission is the shortest in duration, it is 
one of the most expensive segments and provides the greatest risk. It is, therefore, one of 
the most important facets of the space mission. For example, a Delta n launch mission 
costs approximately $100 million for the rocket and payload combined, with each of the 
satellites costing about $13 million. [Ref. 45] The Globalstar constellation of satellites 
will be launched by three different launch vehicles, the Boeing Delta n, the Russian 
Zenit-2, and the French Soyuz-Icare. All three vehicles are Expendable Launch Systems, 
meaning that the launch vehicle is not recovered after use. The Delta n produces 
359,337 kgf of liftoff thrust and carries a Globalstar payload of four satellites with a total 
mass of 1,776 kg. The Zenit-2 provides 769,880 kgf of liftoff thrust and carries a LEO 
payload of 13,740 kg, including 12 Globalstar satellites. Finally, the Soyuz-Icare makes 
411,116 kgf of liftoff thrust and carries a LEO payload of 7,050 kg, including four 
Globalstar satellites. The Delta n launches will take place at Cape Canaveral, Florida, 
with the Zenit-2 launches occurring in Baikonur, Kazakhstan, and the Soyuz-Icare 
launches taking place in France. [Ref. 43] 

4. Ground Segment 

The ground segment of the Globalstar system provides the processing muscle 
required for this complex communications network. The ground segment includes the 
Gateways, Ground Operations Control Centers, Satellite Operations Control Center, and 
the Globalstar Data Network. Due to the bent-pipe architecture of the Globalstar 
satellites, the ground segment of the system is of utmost importance, as it performs the 


76 


majority of work in the system. The ground segment provides the backbone for the 
complex communication and data network incorporated in Globalstar. 

5. Communication Architecture 

a. Gateways 

More than 30 Gateways in the Globalstar system will interconnect the 
satellite wireless network with ground based Public Switch Telephone Networks (PSTN) 
and Public Land Mobile Network (PLMN) infrastructure. [Ref 46] The Gateway takes 
the signal received from the satellite and patches it into the existing land communications 
systems, whether they be line or wireless. This interoperability between Globalstar and 
local telephone and cellular companies is assured and the subscriber maintains a 
convenient single point for billing. [Ref. 43] Each Gateway has the capacity to connect 
up to 1,000 users to these public telephone systems simultaneously. [Ref. 47] 

b. Ground Operations Control Centers 

‘The Ground Operations Control Center’s (GOCC) are responsible for 
planning and controlling satellite utilization by Gateway terminals, and for coordinating 
this utilization with the Satellite Operation Control Center.” [Ref. 35] GOCC’s control 
all ground-based assets and schedule the communication links between the satellites and 
Gateways. The Gateways and satellites then use these parameters to operate 
autonomously. 

c. Satellite Operations Control Center 

The Satellite Operations Control Center (SOCC) controls the spacecraft in 
the Globalstar satellite constellation. Along with a primary SOCC located in San Jose, 
CA, a backup SOCC, located in Sacramento, CA, provides redundant service in the case 
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of a primary SOCC failure. These facilities are charged with controlling orbits, tracking 
satellites and providing Telemetry and Command functions to achieve these goals. 
SOCC’s also serve as the health and status monitors of the Globalstar constellation. 
Furthermore, the SOCC is responsible for monitoring all launch and deployment 
activities. 

d. Globalstar Data Network 

The Globalstar Data Network (GDN) provides the communications and 
data link between the different components of the ground segment, including the 
Gateways, GOCC and SOCC. The GDN enables the Gateways, GOCC’s and SOCC to 
remain in continuous contact with one another through a wide-area network t 5 ^e of 
infrastructure. This kind of link is imperative with the tremendous requirements placed 
on the Globalstar ground system. [Ref. 48] 

6. Architecture 

The command, control and communications architecture is truly the heart of the 
Globalstar system. This is not surprising, considering that Globalstar is primarily a 
communications system. To achieve the lowest possible cost satellite communications, 
Globalstar uses a complex system of signal routing through terrestrial systems, including 
local and regional service providers. A Globalstar user call is first routed through an 
existing local cellular service, if available. In this case, no satellite communications are 
required. If cellular service is not available, however, the Globalstar call will then be 
routed to an overhead satellite. The call is then relayed from the satellite to a Gateway 
(see Figure 17). The Gateway in turn forwards the call through existing ground services 
to its destination. [Ref. 43] 
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Figure 17. Globalstar Frequency Plan. [Ref. 43] 


a. Frequency Plan 

Globalstar communications take place in the C, L and S-bands. The user 
terminal contacts the satellite via a 1.6 GHz L-band signal and receives signals from the 
satellite in the 2.5 GHz S-band. Likewise, Gateways contact satellites via a 7 GHz C- 
band signal and receive on a 5 GHz signal. Globalstar communications can be broken 
down into two links, a forward link, which consists of a Gateway conununicating with a 
satellite, that in turn conununicates with the user terminal. The other link, a reverse link, 
is just the opposite. In the forward link, a Gateway will produce an effective isotropic 
radiated power (EIRP) of 41dBW and yield an Eb/No at the user terminal of 3.9 dB. The 
return link will see an EIRP of -9.2 dBW at the user terminal and an Eb/No of 5.7 dB at 
the Gateway. These values provide for extremely high-quality voice and data 
transmissions. [Ref. 47] 
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b. Frequency Reuse and Cell Management 
Frequency spreading is required by radio regulations, particularly those 
concerning limitations of power flux emitted by the user terminal and satellite. 
Transmission systems must use the power of satellites to maximize capacity, share the 
spectral resource with other services, obey regulations in order to avoid interference, 
offer high availability with excellent quality, and avoid “self-interference” coming from 
multiple coverages. [Ref. 42] To accomplish these goals, Globalstar utilizes a technique 
known as code division multiple access (CDMA). 

CDMA, now also known as IS-95, allows ground stations to receive two 
different signals from two different satellites simultaneously. [Ref. 49] This provides 
continuous, transparent handoffs between satellites. CDMA also permits users to share 
time and frequency allocations by assigning each user a particular code. The receiver 
then accepts only those transmissions that it recognizes as coming from the user’s 
designated unique code. By doing so, Globalstar can handle large numbers of users at the 
same time, operating on the same frequency channel. In addition to simply listening for a 
properly encoded message, Globalstar can also control power in such a way that less 
discrete signals are amplified while others are de-amplified. 

Globalstar users will communicate via three types of user terminals, fixed, 
mobile and personal. The fixed terminal will look like any ordinary fixed line telephone 
booth, but will offer wireless communications in remote areas with very little setup, bi 
this format, communications can be offered to remote, developing areas before the 
infrastructure of a landline is developed. Mobile users will communicate via a car- 
mounted system. This system will offer the accoutrements of an ordinary mobile cellular 
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phone, including hands-free usage and battery charging facilities. The personal, dual¬ 
mode user terminal will be the most widely used of the three terminal types. These 
terminals will closely resemble a common cellular phone in size, shape and function. As 
mentioned earlier, the user will first be connected via existing cellular networks if 
available, but in the event no such service can be utilized, the call will be completed 
through the Globalstar system. In any event, each call will appear to be like any cellular 
telephone call. 

E. ADVANTAGES OF LEO SATELLITE SYSTEMS 

• The low orbits allow them to transmit signals without the troublesome 
half-second delay characteristic of geosynchronous satellites. 

• Because they are lighter and on lower orbits, they are cheaper to launch. 

• Signals relayed by the LEO’s remain stronger because of the lower orbit, 
so they are compatible with handsets the size of cellular phones. 

• The low altitude of the satellites allows easy radio links with portable 
cellular radiotelephones on earth, using small antennas rather than satellite 
dishes. It also supports reuse of radio frequencies, in a similar fashion to 
land-based cellular systems. 

• The system solves the problem of low-orbit satellites "disappearing over 
the horizon’" by combining a large number of satellites in a space-based, 
inter-satellite switching system. 

• Designed to complement, not compete with, land-based cellular systems. 
Land-based cellular will remain the most efficient way to serve high- 
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density areas, whereas LEO satellites will bring communications to remote 
or sparsely populated areas that lack communications. 

• LEO satellites and terrestrial cellular will work together to eventually 
provide a seamless communications service for the entire world. 

• For low-density areas lacking cellular phone networks, LEO satellites will 
be an ideal alternative for mobile telephone service. In sparsely populated 
or underdeveloped areas lacking basic telephone service, satellites can be 
a foundation for an eventual ground telephone system. 

• For ships and aircraft, LEO satellites will provide voice or data links and 
positioning information without the sophisticated on-board 
telecommunications hardware now required. Since satellites are not 
dependent on land-based communications links, they will also play a 
cracial role in crisis response as well as disaster-recovery efforts following 
earthquakes, hurricanes or other natural calamities. 

F. MILITARY APPLICATIONS OF SATELLITE COMMUNICATIONS 

The application of a system such as Iridium, Teledesic, or Globalstar has limitless 
possibilities in the military. Marines in the field could reduce the weight of their 
communication equipment drastically while enhancing the level of their communications. 
Navy ships can enhance their overall communication abilities without the added concerns 
of large antennas and miles of wire throughout the ships. If implemented properly, the 
ability to communicate from anywhere in the world with a hand held phone will 
significantly enhance the fighting capability of the Armed Services. Any unit no matter 
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how large or small could be provided the same level of connectivity afforded to only the 
senior most personnel at this time. 

Without question there is a role for commercial satellite communications in 
support of world-wide military operations. The requirement to rapidly communicate over 
long distances has resulted in an increased dependence upon satellite communications for 
DoD operations. During Operations Desert Shield and Desert Storm and as recent as 
Operation Joint Endeavor in Bosnia, communications planners realized existing 
MILSATCOM systems lacked sufficient capacity to support the enormous 
communications requirements for JTF command operations. As a result, an integrated 
architecture using commercial satellite communications systems to augment existing, 
overburdened, military communications systems is being pursued to resolve today’s 
shortfalls. At the urging of Congress in 1992, DoD began the Commercial Satellite 
Communications Initiative to investigate ways in which the DoD could more effectively, 
and more inexpensively, make use of substantial on-orbit commercial communications 
capacity and thereby lessen its reliance on military systems. The first outgrowth of that 
study was the DOD’s 1993 policy on the use of commercial SATCOM. [Ref. 46] 

Under the Commercial Satellite Communications Initiative (CSCI), DoD planned 
to lease transponders, not connections, on more than a single satellite and from the 
system owner, not from the communications service provider. Following in the spirit of 
the CSCI, the U.S. Navy has been aggressively pursuing the use of commercial wideband 
satellite communications systems as an augmentation to existing military systems. The 
goal of the CNO Special Project Challenge Athena has been to provide the necessary 
communications throughout the fleet to allow JTF commanders afloat the ability to 
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actively participate in joint command decisions and operations. In future visions of Joint 
Vision 2010 (JV 2010) and the Navy’s Information Technology for the 21st Century (IT- 
21), the increased bandwidth and area coverage requirements that can be met by the LEO 
systems will dramatically enhance MELSATCOM systems. [Ref. 46] 

JV 2010 is the conceptual template for how our forces will achieve dominance 
across the full range of miUtary operations in the future. The emerging operational 
concepts of JV 2010 can be characterized as "Network Centric" and the vision of future 
warfare as "Network Centric Warfare." One goal of JV 2010 is to provide warfighters 
with accurate information in a timely manner. Information technology improves the 
ability to see, prioritize, and assess information. The fusion of all-source intelligence with 
sensors, platforms, command centers, and logistics support centers will allow operations 
to move faster. Advances in computer processing and the global network umbrella of the 
LEO systems could provide the capabihty to collect, process and display relevant, fused 
data to thousands of locations simultaneously. This integrated civilian and military 
SATCOM system will ensure that the data is distributed on a real-time basis, making it 
possible for warfighters to use information most effectively. [Ref. 46] 

One example of an existing operational architecture that employs network centric 
operations to increase combat power is the Cooperative Engagement Capability (CEC). 
The operational architecture of CEC increases combat power by networking the sensor, 
C4 and shooters of the CVBGs platforms to develop a sensor engagement grid. The CEC 
sensor grid fuses data from multiple sensors thereby enabling quantum improvements in 
timeliness, track accuracy, continuity, and target ID over stand-alone sensors. To provide 
the networking communications bandwidth required for the integration of sensors and 
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weapons systems, a robust and flexible communications system such as Iridium, 
Teledesic, or Globalstar would be a preliminary requirement. These systems could be 
integrated into the idea of Network Centric Warfare as part of the information grid. 

[Ref. 49] 

Present day acquisition focuses heavily on procurement of intelligence gathering 
and production systems as well as sophisticated weapons platforms and munitions and to 
a much lesser extent on the communication links to support these elements. However, 
modem warfighting intelligence and weapons systems require a vast transmission 
capacity to support them. Command, Control, Communications, Computers and 
Intelligence (C4I) systems are force multipliers which allow smaller, better equipped 
warfighting forces to be more effective. In this era of right-sizing, force-multipliers, like 
C4I systems, and mainline commercial technologies have become increasingly important 
to mission success. [Ref. 50] 

Although large volumes of intelligence information are available to warfighting 
CINCs, today’s MILSATCOM system has insufficient capacity to transmit this 
information, in timely fashion, from national collection and processing facilities to JTF 
and deployed forces. Requirement growth has historically outpaced satellite 
communications capabilities, and the shortfall is becoming greater every year. [Ref. 46] 

The currently planned orbiting capacity of MILSATCOM will not keep pace with 
the increase in capacity required by new services such as video and imagery, and the 
added demands for information to feed new sensors and weaponry. As the demand for 
SATCOM bandwidth increases, the probable method for allocating circuits will be to 
assign MILSATCOM only circuits to protected systems first. The remaining circuits will 
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be allocated to commercial SATCOM systems. Iridium, Teledesic, or Globalstar should 
be among the commercial systems used. [Ref. 46] 

These LEO systems are characterized by a wide variety of services, capabilities, 
and costs allowing flexibility for DoD procurement. Once a SATCOM requirement has 
been designated as a candidate for commercial satellite implementation, the required 
attributes of data rate, power, and coverage of a DoD SATCOM requirement can become 
the focus for matching up with the LEO system. Iridium, Teledesic, and Globalstar will 
provide DoD with higher power transponders, new frequencies, and enhancements in 
antenna technology that will extend the reach of services to smaller platforms such as 
cruisers, destroyers and platoon size units. [Ref. 46] 

The integration of Iridium, Teledesic, or Globalstar into the MILSATCOM 
satellite architecture will enable DoD to meet some of its goals in programs such as JV 
2010 and 11-21. They could provide the networking for DoD Internet functions such as 
email and the World Wide Web as well as transport for tactical and non-tactical data. The 
system’s low latency will allow it to use standard Internet protocols for ease of systems 
integration and the use of off-the-shelf applications, all goals of JV 2010 and IT-21. 

[Ref. 46] 

Through use of a LEO Satellite Network, the Joint Maritime Communications 
Strategy (JMCOMS) networks can interface through Standardized Tactical Entry Points 
(STEP) to the packet data networks of the other services to include the Army’s 
"Enterprise" Network and the Air Forces’ "Horizon" Network. Teledesic will interface 
with the SIPRNet/NLPERNet through the evolving shore communications infrastructure. 
JMCOMS addresses both technical and implementation challenges of integrating 
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Teledesic with a clear strategy. Rapid advances in telecommunications technology and 
products is key. Many off-the-shelf products for routing, addressing, networking and 
network management are available and compatible with the LEO satellite systems. DOD 
should be able to inexpensively install or modify the commercial satellite terminals for 
use on DOD platforms. [Ref 46] 

LEO satellite systems can bridge the gap in voice and high data rate 
communications until military satellite communications systems can provide sufficient 
throughput to meet the warfighter’s requirements. Once future requirements are met 
through enhanced MILSATCOM systems, the LEO systems can provide an on-demand 
surge capability during contingency operations. High data rate duplex systems such as 
military or commercial wideband satellite communications can then be used for virtual 
theater injection by bringing high data rate information such as tactical imagery back to 
regional terrestrial networks. Depending on the future acquisition strategies of DOD 
toward Iridium, Teledesic, and Globalstar, coverage and availability could be assured at a 
reasonable cost. [Ref. 46] 
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V. COMMUNICATIONS MODELING AND SIMULATION 


A. MODELING AND SIMULATION 

This chapter explores the use of modeling and simulation as a tool in 
understanding the current naval surface fire support communication architecture and the 
proposed architecture that support the ELB concepts of OMFTS and STOM. The models 
and supporting employment scenarios are based on research performed while 
investigating OMFTS doctrine and the concept of operations employed by the U.S. 
Marine Corps Warfighting Lab’s Hunter Warrior experiment and the U.S. Navy’s Fleet 
Battle Experiments. Two models were developed and tested employing a PC based, 
object oriented modeling and simulation tool called Extend (version 4.03) developed by 
Imagine That! Incorporated. Extend, an easy-to-use graphical simulation tool, allows the 
user to model complex discrete or continuous systems while varying performance 
parameters. [Ref. 51,52] 

1. Background and Terminology 

A model is a lo^cal description of how a system performs. Simulations involve 
designing a model of the system, carrying out experiments on it through time, and 
measuring the behavior of the model. Models are increasingly being used because they 
enable one to test systems at a fraction of the cost without actually undertaking the 
activities to construct a real world physical representation of the system. This is 
invaluable in the initial concept and development of any new system and its supporting 
principles. It allows evaluation of ideas and identification of inefficiencies before 
expending capital and resources to the final product. Simulation is also important 
because it is used to: gain insight and stimulate creative thinking toward a concept; 
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identify problems before implementation; confirm all variables; and finally, to strengthen 
the integrity and feasibility of a concept. [Ref. 52] The principle benefit of a model is 
that design begins with a simple approximation of a process that is gradually refined as 
understanding of the process improves. Thus, models can always be changed to improve 
accuracy. 

2. Extend Software 

Extend was chosen because it is a popular tool for high level, concept design. 
Extend requires only a 486, or Pentium Pro computer and runs on Windows 3.1. 95, 98 or 
NT by Microsoft or Macintosh or Power Macintosh by Apple. Also, it is user-friendly 
and comparatively inexpensive. Extend is used extensively by Navy organizations 
conducting research in OTH communication concepts, such as SPAWAR, and the Naval 
Postgraduate School. The software uses pie-built object blocks that are the foundation of 
an Extend model. They emulate user-selected functions, actions, and processes of the 
model. 

Represented by icons, blocks are assembled by “dragging and dropping” from the 
Graphical User Interface (GUI) tool bar to the working space. The user then connects the 
blocks in logical order, or desired sequence, while also entering performance parameters, 
or behaviors, into each block through its associated dialog page. Animation allows items 
to be followed during simulation. As the model becomes larger and more complex, the 
user can group blocks, and form process hierarchies with associated inputs and outputs. 
Simulation results are displayed using graphs, tables, sensitivity analysis, and user- 
developed notebooks for input and output performance of data. [Ref. 51] Because 
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network activities are event driven, discrete event simulation is the design basis for the 
modeled scenarios. 

3. Design Steps 

The scenario based network models follow this design sequence: define the 
physical communication architectures required to support the operational concepts; 
develop and build the model through a stepwise, iterative process that includes 
representation of links, nodes, and interfaces; run the simulation, analyze the results; and 
draw conclusions based on model results. This process is presented in the following 
section. The two models are presented in their entirety and then broken down into each 
individual group and what they represent. A discussion of the simulation results follows 
each presentation of the models. 

B. THE EXTEND MODELS 

1. Design Parameters 

The design parameters modeled include bandwidth loading based on user message 
input from previous exercises, delays, and system characteristics. These models assume 
that the maximum bandwidth is used when all units are acting independent of one another 
with sea-based command and control and naval fire support. The user groups are 
selected based on the Marine Corps’ pyramid command and control organizational 
structure of “threes.” For example, the basic infantry unit is the fire team. There are 
three fire teams per squad, three squads per platoon, and three platoons per company. 
Also, there are three companies per battalion and three battalions per regiment. 

The first model discusses a battalion of users whereas the second model 
represents a regiment’s worth of fire support messages. The user groups have established 
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communication links to Navy ships for NSFS. The assumptions for both scenarios are 
summarized as follows: 

• Command and control is sea-based. 

• Units, companies, operate independently of one another. 

• Message inter-arrival times are random. Therefore, the performances of 
the architecture outputs are based on random behavior of the nodes. 

2. Current Naval Gunfire Architecture 

a. Overview 

This model represents the fire support messages of a MEU size element. 
It concentrates on three infantry companies’ calls-for-fire (CFF). The NGF architecture 
is designed for messages to be sent from an infantry company to a Navy ship, which is in 
direct support (see Figure 18). This model can be tripled to show that total amount of 
time it would take a regiment to send its total messages. The initial CFF is shot and the 
follow-on “adjust fire” messages are shot as the probability of “steel-on-target” increases 
as each call is prosecuted. As a CFF is processed, the probability of the round hitting its 
target increases from 70% to 80%, 90%, and finally 100%. The time delay for each 
message being sent is directly proportional to the bandwidth (BW), 2.4 kbps, divided by 
each message size. Also, time delays were put into the system to replicate the time it 
takes Marines to properly send the entire CFF message. 
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Figure 18. Naval Gunfire Support Architecture for Model 1. 


b. User Group 

Each user group represents an infantry company. The Marine company 
block represents nine squads (see Figure 19). Based on the after action reports from the 
Hunter Warrior ’97 exercise and the ITT study mentioned in chapter HI, a 256-bit 
position report (POSREP) message is sent every five minutes. A 700-bit situation report 
(SITREP) message is sent every 15 minutes. Ten percent of the squads (approximately 
three squads) encounter firefights at various times. When a squad is engaged in a 
firelight, a 750-bit CFF message is sent each minute for fifteen minutes based on the 
Hunter Warrior experiment results. 
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Figure 19. Marine Company Hierarchical Block in Extend. [Ref. 51] 


A POSREP is sent every five minutes and a SITREP every 15 minutes. These 
messages are sent to an exit to signify that they are not CFF messages. The CFF 
messages are sent through the ship for fire prosecution. Figure 20 presents the messages 
that are sent out of the program blocks. 
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Figure 20. Messages Sent from Marine Companies in Extend. [Ref. 51] 


As discussed earlier, there are time delays for the messages to reach the ship. The 
first time delay is the approximate amount of time it takes a Marine to completely pass a 
message by voice. The second message time delay is the delay associated with the type 
of communication equipment used. This model uses an AN/PRC-104, high frequency 
(HF) radio with a BW of 2.4 kbps. The message size is divided by the BW to get the 
second time delay. There is also an initial time delay on the ship to represent the time a 
sailor takes to copy down the CFF message. 

c. Naval Gunfire Support Ship 

When the message reaches the ship there is a delay to represent the sailor 
receiving the message. The message is then sent through a process going through the 


95 























































navigation plot, a gun plot, and a 5” 54 console. The message is then passed to a fire 
control computer if the three plots match. Figure 21 shows this process. 



Figure 21. Naval Gunfire Support Ship Modeled in Extend. [Ref. 51] 

Finally, the message passes through the system and the shot is fired. ‘Tire adjustment” 
messages are then sent and the probability of hitting their target is increased. When the 
fifth shot is fired the round has a 100% chance of getting “steel on target.” 
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3. Proposed ELB Naval Surface Fire Support Architecture 
a. Overview 

The F.T.B NSFS architecture represents a Marine Expeditionary Brigade 
(MEB) size force comprised of an infantry regiment supported by three ships in general 
support. The Marine Corps no longer use MEB’s but this model can be scaled larger to a 
Marine Expeditionary Force (MEF) size element and a MEF forward may be regimental 
size. An infantry regiment is composed of three infantry battalions and each battalion has 
three infantry companies. The ELB NSFS architecture (see Figure 22) is designed for 
messages to be sent from an infantry company into a LAWS computer onboard a 
command ship via the Iridium satellite system. Once LAWS decides which ship will 
shoot the request, the message is sent to that ship and the round is fired. The time delays 
for the messages are directly proportional to the message size divided by the BW used by 
the Iridium system. Small delays have been placed in LAWS for database checks and in 
the communications links amongst the ships. 
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Figure 22. ELB NSFS Architecture. 


b. User Group 

The user group represents an infantry regiment (see Figure 23). The 
regiment is composed of three battahons with each battalion having three companies. 
Thus, an infantry regiment is comprised of nine companies (see Figure 19). Three 
platoons of three squads each make up an infantry company for a total of 81 squads in 
this model. The Marine Company icons represent nine squads each. 
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Figure 23. Modeled Infantry Regiment in Extend. [Ref. 51] 


These squads are sending out a 256-bit POSREP message every five minutes and a 700- 
bit SUREP every 15 minutes. Ten squads send CFF messages (750-bits) every minute 
for 15 minutes at various times while in firefights. The POSREP and SITREP messages 
are sent to decision blocks for differentiation between routine and CFF messages. 
Routine messages are then sent to exit blocks. The time delays in the user block are the 
message length divided by the 2.4 kbps Iridium bandwidth. When the message leaves the 
program block, 18 bits are added to each message for encryption and IP addressing. 

c. Satellite Block 

The satellite picture (see Figure 24) represents the Iridium LEO system 
modeled in a hierarchical block (see Figure 25). This block pulls messages through the 
satellite system to the ship. 













Figure 24. Satellite Hierarchical Block. 

Figure 25 is the window that is called up when the satellite icon is 
“clicked-on.” The messages are sent to a queue, where they wait to be pulled from the 
“Access” block. Once messages are pulled, a time delay is applied to the messages that 




Figure 25. Iridium LEO System Modeled in Extend. [Ref. 51] 
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is directly proportional to the message size divided by the bandwidth, 2.4 kbps. The 
“Access” block (see Figure 26) is designed to make the modeled LEO system realistic in 
the sense that a call has a probability of not getting connected. A random number 
probability block is inserted to give calls a 98% chance of completion. Two percent of 
the calls will be returned through the block for call completion and a time delayed is 
applied to model this retransmission. 



Figure 26. “Access” Block for LEO modeled system. [Ref. 51] 


d. LAWS Block 

CFF messages enter LAWS via the narrow-band satellite link into 
the main LAWS terminal in the SACC onboard the command ship (see Figure 27). The 
message is then sent through various time delays in sequence to match target with 
munitions and check the status of firing platforms (see Figure 28). 
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Figure 27. LAWS NSFS Architecture 


Once LAWS has matched the OFF target with the appropriate munitions, and the 
message passes through the time delay block to check the platform status, the message is 
sent to the appropriate firing platform. To simulate the platform status changes the 
message has a 5% chance of being returned due to the unavailability of a particular 
munitions required. When the message makes it through the delay blocks and the 
appropriate firing platform processes the CFF message, the message is then sent to an 
exit block. This process occurs for every CFF message. As mentioned earlier, the 
POSREP and STTREP messages are sent to an exit block early in the process. 
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Figure 28. LAWS Modeled in Extend. [Ref. 51] 


C. RESULTS 

The models were run ten times each. In each run, 100% of the messages were 
delivered successfully. Only the 750-bit CFF messages were processed through the 
entire fire support communication architecture. The POSREP and SITREP messages 
were given early exit blocks. The average delay times of all the CFF messages were 
added together for each separate architecture and the average of these delays were used 
for input into the Joint Conflict and Tactics Simulation. Table 4 displays the results of 
the model runs. Delay times are the averages of the ten runs. The naval gunfire support 
architecture produced an average delay time of 14.7 minutes for a Battalion Landing 
Team (BLT) size force. The ELB NSFS architecture produced an average delay time of 
9.1 minutes for a Regimental Landing Team (RLT) size force. These are the two times 
that were entered into JCATS as the time it takes for the Forward Observer to 
successfully get a CFF shot. 
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NGF Architecture 

ELB NSFS Architecture 

Total Messages Sent 

301 

894 

Total CFF Messages Sent 

58 

161 

% CFF Messages 

19.3 % 

18.0 % 

Average Message Time 

14.7 minutes 

9.1 minutes 


Table 4. Extend Model Results. 


D. SUMMARY 

The two delay times were the pieces of information desired to be gained by using 
Extend for input into JCATS. Although there was a slight difference in the percentage 
of CFF messages in the NGF architecture compared to that for the ELB NSFS 
architecture, the ELB architecture contained more information sorting. Both 
architectures realistically modeled the processes for obtaining sea-based fire support. 
Using data gathered in previous exercises was invaluable for making the results of the 
model realistic. 
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VI. COMBAT SIMULATION MODELING 


This chapter examines potential changes in an amphibious assault scenario using 
the Joint Conflict and Tactical Simulation (JCATS) Combat Simulation Model to 
simulate a portion of Exercise KERNEL BLITZ (KB). The call for fire delay times 
calculated using Extend were inserted into JCATS to determine their affect in a combat 
scenario. 

A. JCATS COMBAT MODEL 

JCATS was developed by Lawrence Livermore National Laboratory. It evolved 
from a merger of the Joint Tactical Simulation (JTS) and the Joint Conflict Model (JCM). 
JCATS is a multi-sided, high resolution, entity level combat simulation model used for 
throughout the Department of Defense (DOD) and other U.S. government agencies for 
combat and conflict training, exercises, analysis, experiments, and rehearsals. JCATS 
can model strategic through tactical levels across the broad spectrum of war, from Joint 
Task Force head-to-head engagements to individual conflicts in operations other than 
war. Some of the most important features and capabilities of JCATS include: 

• Amphibious landings and submarine play 

• Platforms blocking line of sight(LOS) 

• Four levels of acquisition 

• Peripheral acquisitions 

• Detailed trafficability model 

• Multi-story urban operations with windows, doors and interior direct fire 
engagements with solid object interaction from buildings 

• Precision guided weapons with supporting laser spotting 


105 




• FO to direct support asset automatic call for fire 

• Detailed ROE settings 

• Dynamically controlled non-homogeneous aggregation/disaggregation and 
mount/dismount functions 

• Detailed human factors including fatigue, secondary suppression and 
fratricide. [Ref. 53] 

B. OBJECTIVES 

Using a large-scale U.S. Marine Corps and Navy amphibious exercise as the 
operational framework for the model, the JCATS simulations in this study will attempt to 
capture the unique features of amphibious combat operations and emerging technologies 
for littoral combat in the next century. 

The objective of this simulation is to examine the impact of changes in sensor-to- 
shooter delay times on the combat effectiveness of ground forces. Using the current call- 
for-fire system as the baseline. Naval Surface supportability will be considered. 
Interaction between the performance characteristics is expected. As the simulations are 
conducted, a preliminary analysis may indicate the need to reduce the number of 
independent characteristics that require a full examination. Future research to gain 
additional insight into the affects of sensor-to-shooter delay times in amphibious 
operations may be based on the results of this thesis. 

C. MODEL DESCRIPTION 

1. Fleet Battle Experiment Echo (FBE-Echo)/KB 

The future of naval warfare is being shaped in the Fleet Battle Experiments. The 
overriding purpose of these experiments is to test innovative concepts and technologies in 
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a real-time battle scenario. In particular, FBE-Echo will test future capabilities in both 
asymmetrical and traditional maritime environments. [Ref. 54] FBE-Echo will be 
conducted in conjunction with Kernel Blitz (KB), an umbrella exercise for a series of 
naval force operational events during 1999 on the West Coast of the United States. KB 
“Prime” is a traditional large-scale amphibious assault exercise, which will exercise a 
real-world contingency plan. For the purposes of this thesis, the actual amphibious 
assault portion of KB will be referred to as KB-99. The analysis conducted in this thesis 
used the first phase of the tactical operations during KB-99 of one of the U.S. Marine 
infantry battalions. Second Battalion, Fifth Marine Infantry Regiment (2/5), as the tactical 
framework for the simulated scenarios. 

2. KB-99 Political and Military Background Details 

The KB-99 scenario is based on U.S. Military Forces conducting httoral 
operations against a generic third world country. Orange, and Orange supported rebels in 
country Green. These countries are located on the southwestern coast of the United 
States. The country of Orange consists of southern California, Arizona, and Nevada. 
Green consists of northern California. The scenario’s geopolitical situation is intended 
to be representative of one which could occur in 1999 in a sensitive region, with 
hostilities eventually spanning to low-mid intensity conflict. 

Orange is a religious oligarchy, generally hostile towards Western governments 
and views Western society as corrupt and immoral. Orange has supported insurgency 
movements in Green that support reunification with Orange. These movements include 
groups that use violence and terrorism in country Green. Orange views U.S. military 
operations in the area as a challenge to its own goal of regional hegemony. Green has 
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been democratic since its inception. It has established good relations with the Western 
Powers and is a strong supporter of U.S. activity in the region. 

Militarily, Orange has the capacity to secure regional hegemony if unchecked. 
This will threaten U.S. vital interests in oilfields, exports, and manufacturing sites nearby. 
Neighboring countries posses the technology for inter-continental ballistic missiles 
(ICBM), which if captured by Orange, will have a devastating effect on the regional 
balance of power and U.S. economic interests. Orange’s current missile and mining 
capabilities allow them to threaten sea lanes. Intelligence estimates indicate that Orange 
has chemical and biological warfare capabilities. Their ongoing development of these 
capabilities has bolstered their recent actions. 

3. Current Military Situation 

Recent Orange naval operations in the Straits of Barbara, increased tensions and a 
forward deployed force consisting of an Amphibious Ready Group/Marine Expeditionary 
Unit (MEU) and Carrier Battle Group was ordered to the region. Orange insurgents 
intensified activity. The Green capital, Francisco City, was hit by a major earthquake and 
insurgents seized opportunity to interfere with commercial shipping in Francisco Bay. 
Green requested U.S. assistance, and U.S. Forces began humanitarian and peace 
operations in support of Green in Francisco Bay area. Orange retaliated by attacks on 
military and civilian shipping off the coast of Southern California. U.S. military forces 
were tasked to open sea lanes and neutralize Orange's ability to militarily influence 
neighboring nations and threaten U.S. interests in the region. U.S. air and sea offensive 
began against Orange missile sites, weapons of mass destruction facilities, and mine 
facilities. By April 10, strategic and operational naval fires commenced against Orange 
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armored forces, airfields, logistics bases, and command and control sites. Preparation has 
begun for the seizure of San Pendleton Island (a notional island consisting primarily of 
Camp Pendleton, separated from the mainland by approximately 10 miles) to facilitate 
the introduction of follow on forces (see Figure 29). [Ref. 54] 



Figure 29. San Pendleton Island. [Ref. 55] 


4. Amphibious Assault Plan 

Regimental landing Team One (RLT-1) consists primarily of three infantry 
battalions, a tank company, an artillery battery and supporting attachments. RLT-1 is 
assigned the mission of seizing RLT OBJ A, neutralizing enemy forces, and securing 
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cross-channel sites in order to facilitate the rapid introduction of follow on forces. RLT- 
I’s plan includes a surface assault in Amphibious Assault Vehicles (AAVs) by (2/5), a 
helicopter assault by First Battalion, Seventh Marine Infantry Regiment (1/7) and 
landings of the remaining forces by landing craft. 

5. 2/5 Scheme of Maneuver 

The combat scenario in this thesis is generally based on the actual exercise 
mission and activity of 2/5, its attachments, and the combat activity closely tied to 2/5’s 
maneuver during KB-99 through the first phase of the operation. 

The operations by 2/5 were preceded by the landing of a platoon of Light 
Armored Vehicles (LAV) via Landing Craft Air-Cushioned (LCAC) with the battalion 
reconnaissance teams. Therefore, the beach area is considered clear of enemy forces. 
Golf Company 2/5 (G 2/5), lands across Red Beach and moves to an assembly area near 
the entrance to Las Pulgas Canyon. Echo Company 2/5 (E 2/5) moves immediately to 
clear the high ground west of Las Pulgas Canyon, generally along Piedra de Lumbra 
Canyon. 

Once this high ground is cleared, G 2/5 clears Las Pulgas Canyon and establishes 
a support by fire position southeast of RLT Objective A. E 2/5 then attacks to seize RLT 
Objective A. G 2/5 and the remaining battalion elements consolidate near the objective 
and prepare for the next phase (see Figure 30). 
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Figure 30. KB-99 Amphibious Assault Graphical Depiction 


The following is a brief description of the primary activities of each unit in the 
scenario: 

G 2/5: 

• Become main effort 

• At H-hour, Conduct amphib assault across red Beach and destroy enemy 
near RLT obj 1. 

• Establish Assembly Area near checkpoint 73. 

• Become supporting effort 


111 













• On order, clear Las Pulgas Canyon. 

• Establish Support by fire position near checkpoint 9. 

• On Order, establish Battle Position near Checkpoint 81 A, oriented WNW 
to prevent enemy penetration from Homo Canyon. 

E 2/5: 

• Become Supporting effort. 

• At H-hour, Conduct amphib assault across red Beach, following in trace of 
G Company, and move immediately to checkpoint 10. 

• On order, clear high ground west flank of Las Pulgas Canyon in order to 
prevent enemy interference with main effort’s movement up Las Pulgas 
Canyon. 

• On order, become main effort. 

• Attack along and neutralize enemy near RLT obj 2 in order to prevent 
enemy movement along Basilone Rd. 

• On order, consolidate near RLT obj 2, protecting right flank of battalion 
position. 

81mm Mortar Platoon: 

• At H-hour, land on Red Beach. 

• Follow in trace of E Company and establish firing positions to support 
maneuver elements. 

• Displace by section to provide fires in support of attack on RLT obj 2. 

• On order, displace to near RLT obj 2 and provide fires in support of 
consolidation. 


112 



• Initial firing positions near grid 592855. 

• Secondary firing positions near grid 591899. 

Each simulation scenario models the combat operations of 2/5 fi'om the beach to 
the first major objective. The blue side represents the U.S. Forces and the red side 
represents country Orange Forces. The blue forces are generally aggregated to the 
platoon level, and consist of two mechanized infantry companies, weapons company 
assets, and naval surface fire support (NSFS) assets. In each scenario, they are opposed 
by red forces consisting of elements from a mechanized infantry battalion with soviet 
block weapons and equipment, damaged and dispersed from several weeks of intense 
bombardment by naval and air forces. The red forces are generally dispersed in squad 
sized elements, deployed in the general area of their parent company. The red forces 
delay and defend until they can determine which canyon the blue forces are attempting to 
penetrate. Their intent is to then rapidly reorganize their remaining forces for a counter¬ 
attack to destroy the blue beachhead. 

D. SIMULATION RESULTS 

The scenario described above remained constant throughout all simulation runs; 
therefore allowing the delay times determined previously to be the primary variable. The 
delay time from sensor-to-shooter was set initially to model the current call for fire 
system. The delay time then was altered to match those of the proposed system. Each 
scenario was run ten times, using the JCATS Simulation Executive batch program. 

We chose to condense the JCATS simulation results into four different categories. 
We consider these to be are the measures of effectiveness pertinant to this thesis for the 
given scenario. Table 5 illustrates the four MOE’s chosen, while the following is 
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description of each MOE and the results concerning each. The DDG platform was used 
in the model to represent NSFS. 



j 

1 First DDiG 

Last DDG 

i . 

Total Run 

#QQQ 1 

1 


shot 

shot 

time 

sdiots 1 

1 j 

h4 Minute Delay Time 

1 

1 

Run 1 


47.04 

162.93 

:|g2g2 

13 j 

I Run 2 


49.88 

178.95 

191.97 

13 j 

jRun 3 


25.75 

214.27 

214.27 

13 1 

I Run 4 


47.92 

170.68 

192.2 

13 i 

jRun 5 


76.45 

160.27 

196.52 

10 j 

jRun 6 


44.69 

187.32 

191.86 

14 j 

{Run 7 


48.77 

180.1 

193.79 

15 { 

Run 8 


62.8 

177.54 

191 

10 1 

jRun 9 


51.71 

175.53 

189.72 

10 i 

jRun 10 


27.89 

172.62 

189.81 

18 j 

j 


48.29 

178.021 

193.406 

12.9 1 

I 






{9 Minute Delay Time 

j 

.1 


j 

jRun 1 


9.62 

182.76 1 

191.-^ 

CVJ 

CM 

JRun 2 


9.5 

182.16 

189.88 

CM 

CM 

|Run3 j 


10.34 

183.75 1 

191.65 

21 J 

{Run 4 i 


9.36 

182.93 1 

191 

20 1 

{Run 5 


9.61 • 

192.09 

193.36 

21 1 

iRun 6 

; 

9.43 i 

181.66 1 

192.53 

22 j 

{Run 7 

j 

9.59 1 

190.17 i 

193.23 

20 1 

iRun 8 


9.58 1 

181.5 1 

191.07 

20 1 

jRun 9 1 

1 

9.67 ! 

180.19 1 

189.99 I 

21 1 

iRun 10 

i 

i 

9.89 1 

189.45 ! 

190.55 j 

17 I 

i i 

j 

9.659 j 

184.666 j 

191.47 1 

20.6 I 


Table 5. JCATS Simulation Results. 


1. Time of first DDG shots fired 

This MOE represents the time during the scenario that the first NSFS assets were 
used to support the mission. The results show a significant difference (38.6 minutes 
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average) between the two variable delay times used. It was determined that this occurred 
because the delay time for the first ten runs was so long that organic fire support assets 
were better suited to complete the initial fire support missions in a more timely manner. 

2. Time of last DDG shots fired 

This MOE represents the time during the scenario that the last NSFS assets were 
used to support the mission. For these numbers to be usable they must be combined with 
the total run time of the scenario. The results show a slight difference (8.6 minutes 
average) between the scenarios. It was determined that this is also directly related to the 
unacceptable length of 14 minutes delay time. The scenario was forced to complete the 
mission using organic fire support assets because the communication delays times were 
too long for NSFS to be used late in the scenario. 

3. Total Run Time 

This MOE represents the total minutes it takes to complete the mission/reach the 
objective. The results show a slight advantage (1.9 minute average) is gained when using 
the proposed communication architecture. We feel that this time will continue to increase 
with increases in the fidelity of the JCATS model. 

4. Number of DDG shots fired 

The MOE represents the total number of times the surface ships were called upon 
and actually put rounds on target. The results show a difference of almost 8 fire mission 
per scenario. We determined this shows that the effectiveness and more importantly the 
usefulness of Naval Fire Support significantly increased with a faster sensor-to-shooter 
communication structure. 
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Clearly the results show that the delay time of the sensor-to-shooter 
communication structure does affect mission accomplishment. With longer 
communication delays the mission was still accomplished, but other fibre support assets 
were required and the mission took slightly longer. This will affect follow on mission 
accomplishment under the OMFTS umbrella. Ground forces will rely on naval assets in 
the littoral regions. 
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vn. CONCLUSIONS AND RECOMMENDATIONS 


A. SUMMARY 

OMFTS and STOM seek to extend the littoral batdespace by placing emphasis on 
sea-based fire support and command and control. Maximizing the use of naval surface 
fire support for these advance doctrinal concepts requires OTH communications. Man- 
portable high frequency communications can reach the distances defined in OMFTS (100 
miles OTH and 200 miles inland) but may be spotty due to skip zones. Also, HF 
communications will not provide the digital communications capability that technology 
provides in today’s world. Low earth orbiting satellites provide worldwide coverage, and 
digital communications, accessible from the remotest areas. 

Advances in the fire support systems. Land Attack Warfare System, and 
Advanced Field Artillery Tactical Distribution System, require that a digital 
communications network is used. OMFTS and STOM require a reliable OTH 
communication network. The ability of PalmELVIS to provide call-for-fire messaging, 
digital mapping and imagery, and GPS location must be exploited. The fact that these 
functions fit in a palm-size computer that are inter-operable with LAWS, AFATDS, and 
GCCS provides Marines with an extremely light-weight communications suite. 
PalmELVIS using an Iridium telephone provides forces improved fire support capable of 
communicating anywhere in the world. 

As researched and illustrated in this thesis, this fire support architecture (see 
Figure 30) greatly reduced the time for a “shot out.” The current naval gunfire 
procedures and architecture resulted in a time of 14.7 minutes. The new architecture 
using PalmELVIS, AFATDS, LAWS, and the Iridium LEO system resulted in a time of 


117 



9.1 minutes. This is a 64.5% reduction in time. This time had a direct impact in 
accomplishing objectives on land. 



Figure 31. Proposed ELB Fire Support Communication Architecture. 


B. FUTURE RESEARCH 

This thesis has identified many areas for future research. This study used the 
results of the Hunter Warrior exercise and an ITT simulation to gain insight into 
information exchanges for calls-for-fire. This area needs to be investigated further to find 
out appropriate information exchanges in terms of amount of messages transferred, 
message sizes, and frequency. Communication models can be developed using this 
information that will aid planners by identifying critical vulnerabilities in a network. 
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The communication architecture models developed for this thesis can be built on 
and improved. This research used the Extend software to model the current naval gunfire 
architecture and the authors’ proposed ELB naval surface fire support architecture. 
These models can be expanded or future research could use a more powerful 
communication modeling software such as OPNET. Valuable information concerning 
delay times, collisions, and network performance can be gained from communications 
modeling. The use of combat simulations and the ability to input communication effects 
provides another vital area of research. By modeling systems before acquiring them, 
their impact on the battlefield can be viewed. 

Finally, the military applications of low earth orbiting satellite systems must be 
studied further. These systems will be able to provide greater bandwidth in the future. 
The introduction of Teledesic in 2003, able to provide T1 capability to dismounted users, 
provides the military great opportunities. New munitions with greater ranges will 
provide all Marines the ability to call in fires from the sea. LEO systems can be exploited 
for Marines to connect to these firing platforms from any terrain. 

C. CONCLUSION 

Sea-based fire support must be improved to make OMFTS and STOM a reality. 
The introduction of the AAAV and the MV-22 Osprey will increase the speed that 
Marines can reach their objectives, but they cannot accomplish their missions without 
fast, reliable, and “all-weather” naval surface fire support. The Extended Range Guided 
Munition (ERGM), Tactical Tomahawk, and the Land Attack Standard Missile (LASM), 
will provide Marines the munitions necessary to engage a wide range of targets well 
inside the ET .R umbrella. Without a fast and reliable fire support communications 
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architecture, the new doctrinal concepts and munitions will be wasted. A fire support 
architecture for extending the littoral battlespace that can exploit available and emerging 
technology will serve as the backbone for the littoral doctrines. 
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